OWASP TOP-10：Webアプリケーションセキュリティの実用的な外観

こんにちは、こんにちは！ Ivan PritulaとDmitry Agapitovは、人々の生活をより快適で快適にするソリューションを開発しています。 今日は、新しいサービスの1つである支払いアグリゲーターSimplePayを紹介します。 私たちが行うことはすべて、一般的に不完全性、特に特定のソフトウェアソリューションの不完全性に耐えることが困難なことです。 当社の製品が生まれるのは、卓越性を追求することです。 私たちは最善を尽くしますが、私たちがどれほど近いかは判断することではありません。



みんなにもっと興味を持ってもらえるように、私たちはサービスを宣伝しません（少しだけですが）。 代わりに、最初の一連の出版物を用意しました。これらの出版物は、Webアプリケーションのセキュリティなど、魅力的で非常に関連性の高いトピックに専念します。 既存のインターネットプロジェクトに関連する危険性を明らかにし、平易な言葉で、データセキュリティ問題の些細な詳細に対する責任あるアプローチの重要性を伝えます。 私たちの記事があなたにとって役に立たないことを願っています。 あなたは私たちをもっとよく知っていると確信しています。

Webアプリケーションのセキュリティ

現代の世界には、文字通りあらゆる段階で、あらゆる瞬間に何千もの脅威と潜在的な危険があります。 私たちの生活の不可欠な部分となっているWorld Wide Webも例外ではありません。



サイバー犯罪はこれまで以上に発展しています。結局のところ、ほとんどすべての企業がインターネット上に独自のWebサイトを持ち、ネットワーク上の攻撃者は完全に匿名のままでいることができます。



さらに、インターネット上にWebサイトを持つすべての企業は、3つのタイプに分類されます。

• サイトが既に壊れている人。
• サイトがまだ壊れていない人。
• 主な攻撃ベクトルに精通しており、アプリケーションを保護している人。

3番目のカテゴリの代表者にとって、これ以上のプレゼンテーションは非常に興味深いものではありません。 残りの2つのカテゴリは、少なくともWebアプリケーションへの攻撃の主なベクトルを認識し、実際のアプリケーションの可能性を認識している必要があります。結局のところ、ほとんど保護されています。



実用化の可能性を強調するのは偶然ではありません。 理論を知っているだけでは脅威の本当の範囲を理解することはできないと考えています。結局のところ、理論上はあまり怖くないように見えない脆弱性は、しばしばビジネスに悲惨な結果をもたらす可能性があります。



脅威の数はビジネスの成長に比例して増加していますが、長期的な実践が示しているように、攻撃の99％は、システム管理者が設定とパスワードを設定して使用しているため、着信データの検証に関する12個の標準エラー、またはインストール済みのサードパーティソフトウェアコンポーネントの脆弱性、または不正行為によって発生しますデフォルトで。



OWASP （Open Web Application Security Project）コミュニティは、攻撃ベクトルと脆弱性の分類に関与しています。 これは、ソフトウェアセキュリティの分析と改善に焦点を当てた国際的な非営利組織です。



OWASPは、Webアプリケーションに対する攻撃の10の最も危険なベクトルのリストを作成しました。このリストはOWASP TOP-10と呼ばれ、一部の人々に多額の費用をかけたり、ビジネスの損失などビジネスの評判を損なう可能性のある最も危険な脆弱性を含んでいます。



この入門記事では、OWASP TOP-10リストを確認し、一連の記事「Webアプリケーションの保護の理論と実践」のフレームワーク内で、これらの各攻撃ベクトル、実際の操作方法、実際のビジネス例を使用した危険度、およびWebアプリケーションおよびWebサービスを保護するための実用的な方法。



プレゼンテーションをできるだけアクセスしやすくすることで、技術専門家だけでなく、時には侵入者によって破られてオンラインビジネスに従事するまで幸せな無知のままであるビジネスオーナーやマネージャーにも情報を伝えるために、それらにかかっている重大な危険を知っている。



行きましょう。

1.注射

原則として、すべてのデータは特別なデータベースに保存され、その呼び出しはクエリの形式で構築され、ほとんどの場合、特別なSQLクエリ言語（構造化クエリ言語-構造化クエリ言語）で記述されます。



たとえば、ユーザーがサイトで個人データを編集したり、アンケートに記入したりする場合、アプリケーションはデータを受信、追加、変更、または削除するためにSQLクエリを使用します。 ユーザーからのデータの検証が不十分な場合、攻撃者はSQLクエリの一部を含むアプリケーションのWebインターフェイスの形式に特別なコードを挿入できます。



このタイプの攻撃はインジェクションと呼ばれます。この場合、最も一般的なのはSQLインジェクションです。 これは危険な脆弱性であり、攻撃者がデータベースにアクセスして、意図しない情報を読み取り/変更/削除できるようにします。



たとえば、名前と姓とともにアカウントの残高を変更したり、他人のアカウントの残高を調べたり、機密の個人データを盗んだりします。



この脆弱性は、ユーザーから受信したデータの検証が不十分な結果です。 これにより、攻撃者は、たとえばWebフォームで、アプリケーションを「だまし」、不正なデータの読み取りまたは書き込みを可能にする特別に準備された要求で、「パームオフ」できます。



一般に、このタイプの攻撃の一般名は「検証エラー」であり、これに適用されるのはSQLインジェクションだけではなく、このベクトルについて複数回言及します。

2.認証システムとセッションストレージの欠点（壊れた認証とセッション管理）

あるユーザーを別のユーザーと区別するために、WebアプリケーションはいわゆるセッションCookieを使用します。 ログインとパスワードを入力し、アプリケーションが許可すると、ブラウザストレージに特別な識別子が保存されます。その後、ブラウザはWebアプリケーションのページに対するすべてのリクエストでサーバーに提示します。 これは、Webアプリケーションがあなたがあなたであると理解する方法です。



識別子が攻撃者に盗まれ、システムがセッションのIPアドレスなどのチェックを実装しなかった場合、または1つのセッションで複数の接続を確認した場合、攻撃者はアカウントの権限でシステムにアクセスできます。 また、インターネットバンクまたは支払いシステムキャビネットの場合、そのような不正アクセスの結果を簡単に推測できます。

3.クロスサイトスクリプティング-XSS（クロスサイトスクリプティング）

Crossiteスクリプティングは、実行のためにJavaScriptコードをユーザーのブラウザーに送信できるようにする別のユーザーデータ検証エラーです。 この種の攻撃はHTMLインジェクションとも呼ばれます。これは、その実装のメカニズムがSQLインジェクションに非常に似ているためですが、後者とは異なり、インジェクトされたコードはユーザーのブラウザーで実行されます。 これは何でいっぱいですか？



まず、攻撃者はセッションCookieを盗むことができます。セッションCookieの結果は2番目の段落、文字通り上記の2つの段落で説明されています。 すべてのアプリケーションサーバーがこのタイプの攻撃に対して脆弱なわけではないことに注意する必要があります。これについては、段落5で個別に説明します。



第二に、感染したページのフォームに入力されたデータが盗まれる可能性があります。 また、機密の個人データ、またはさらに悪いことに、クレジットカード情報とCVCコードが含まれる場合があります。



3番目に、JavaScriptを使用して、ページ上のデータを変更できます。たとえば、銀行振込の詳細があり、攻撃者はそれを偽装して偽のデータに置き換えることができます。

4.安全でない直接オブジェクト参照

このタイプの脆弱性は、ユーザーデータの検証が不十分な結果でもあります。 その本質は、個人メッセージや顧客カードなどの機密データを表示する場合、識別子を使用してオブジェクトにアクセスし、ブラウザーのアドレスバーに明確な形式で送信され、オブジェクトへのアクセス権の検証が実装されていないという事実にあります。 たとえば、個人的なメッセージを表示するページがあり、次の形式のアドレスがあります。



mysite.ru/read_message.jsp?id=123654



「id = "の後の番号を確認すると、他の人のプライベートメッセージを読むことができます。 この脆弱性の悪用は非常に簡単で、特別なスキルはまったく必要ありません。ブラウザのアドレスバーの数字を整理して結果を楽しむだけです。 逆説的に思えるかもしれませんが、かなり大きなヨーロッパの支払いシステムがこの小児期の病気の影響を受けることがありました。

5.安全でない構成（セキュリティの構成ミス）

Webアプリケーションのセキュリティには、すべてのインフラストラクチャコンポーネント（アプリケーションコンポーネント（フレームワークなど）、Webサーバー、データベースサーバー、プラットフォーム自体）の安全な構成が必要です。 多くの場合、サーバーコンポーネントのデフォルト設定は安全ではなく、攻撃の機会が開かれます。 たとえば、XSS攻撃中にJavaScriptを介したセッションCookieの盗難は、cookie_httpのみの設定がデフォルトでオフになっているために可能です。



正しいサーバー構成とcookie_httponlyオプションを有効にすると、JavaScriptを介してセッションCookieを取得することはできませんが、多くの場合、このシンプルで重要な設定は、支払いシステムの個人アカウントなどの重要な場所にありませんでした。



子供の脆弱性のもう1つの例は、Redis、Memcachedなどのデータベースサーバーでのデフォルト設定の使用です。サーバーのパブリックIPアドレスでクローズドサービスを利用できる場合があり、デフォルトでメーカーが設定したパスワードが使用されました。 これにより、攻撃者はデータを簡単に読み取ったり変更したりできますが、その中にはセッションCookie（多くの場合、既にわかっています）とブラウザーでユーザーに表示されるデータがあります（XSS攻撃の使用も可能にします）。



さらに、ソフトウェアは最新でなければなりません。脆弱性は、さまざまなソフトウェアコンポーネント（オペレーティングシステム、Webサーバー、データベースサーバー、メールサーバーなど）で毎日発見されています。 また、アプリケーションが正しく記述され、すべての受信データを慎重にチェックし、一般に十分に保護されている場合でも、OSやWebサーバーにある時点で脆弱性が存在するわけではありません。

6.安全でない重要なデータ（機密データの露出）

多くのWebアプリケーションは、クレジットカードや認証資格情報などの機密データを保護しません。 攻撃者は、自分のweak兵目的で使用するために、このような弱く保護されたデータを盗んだり変更したりできます。



最も簡単な例は、HTTPを介してデータを送信することです。 実際、HTTPを介して送信されるデータは暗号化されておらず、ユーザーのコンピューターからWebサーバーにデータが渡されると、データは多くの異なるノードを通過します：オフィスルーターまたはホームルーター、プロバイダールーター、チャネル上のルーター、データ内のルーターサーバーのホスティングプロバイダーの中心など。 マルウェア、いわゆるスニファ、すべてのトラフィックを読み取り、攻撃者に渡すプログラムは、これらの各ノードに隠されている可能性があります。 後者は、個人データとクレジットカードデータのデータを調べます。



このようなデータは、ブラウザの対応するアドレスバーに示されているように、HTTPSプロトコルを介して排他的に送信する必要があります。







SSL証明書の別のタスク（つまり、HTTPSでの認証と暗号化に使用される特別なキーの名前）は、このサイト専用に発行されたことを確認することです。 証明書の有効期限が切れているか、改ざんされている場合、次の図が表示されます。







別の例は、パスワードやクレジットカード番号などの機密データの暗号化の欠如です。 データが暗号化されている場合、サーバーへの不正アクセスの場合でも、攻撃者は重要なデータを盗むことができません。 特に、不可逆ハッシュ関数をパスワードに適用する必要があります。暗号文を復号化することはできず、入力されたパスワードの暗号文を生成し、データベース内のパスワードと比較することでパスワードを検証します。

7.アクセス制御機能の欠如（Missing Function Level Access Control）

名前が示すように、脆弱性の本質は、要求されたオブジェクトへの適切なアクセスの可用性の検証の欠如です。



ほとんどのWebアプリケーションは、ユーザーインターフェイスにデータを表示する前に権限を確認します。 ただし、アプリケーションは、機能を要求するときにサーバー上で同じアクセス制御チェックを実行する必要があります。 結局のところ、AJAXテクノロジを使用してバックグラウンドで非同期的に送信される補助サービスリクエストがさらに多くあります。



要求パラメーターが完全にチェックされない場合、攻撃者は適切な許可なしにデータにアクセスする要求を偽造できます。



この脆弱性の特定の、そしておそらく最も一般的なケースとして、私たちはすでに記事のパラグラフ4で検討しています-プライベートメッセージでのユーザー検証の欠如。

8.クロスサイトリクエストフォージェリ（CSRF / XSRF）

CSRF攻撃ベクトル（XSRFとも呼ばれる）により、攻撃者は、追加のチェックが実装されていない被害者に代わってサーバー上でアクションを実行できます。



たとえば、資金を別の口座に送金する支払いシステムには、次の形式のページがあります。



demobank.com/transfer_money.jsp？ transfer_amount = 1000＆ transfer_account = 123456789



ここで、 transfer_amountは転送する金額であり、 transfer_accountは資金を転送する口座番号です。



被害者が攻撃者によって作成されたWebサイトを訪問すると、支払いシステムの上記のページにリクエストが密かに送信されます。 その結果、お金は攻撃者の口座に送られ、その後すぐにビットコインと迅速に交換されるか、返金不可の別の支払いシステムに送金され、それらを取り戻すことはできません。



被害者は支払いシステムで以前に認証されていて、アクティブなセッションを開く必要があると想定されています（たとえば、支払いシステムのページは別のブラウザタブで開かれています）。



問題は非常に簡単に解決されます。これについては、CSRFに関する別の記事で説明します。

9.既知の脆弱性を持つコンポーネントの使用

多くの場合、Webアプリケーションは、サードパーティ企業が提供する特別なライブラリまたは「フレームワーク」（英語-フレームワーク）を使用して作成されます。 ほとんどの場合、これらのコンポーネントはオープンソースです。つまり、あなただけでなく、脆弱性を含むソースコードを研究している世界中の何百万人もの人々がそれらを持っていることを意味します。 そして、彼らはこれを決して失敗していないことに注意すべきです。



また、データベースサーバー、Webサーバーなどのシステムの下位レベルのコンポーネント、そして最終的にはカーネルに至るまでのオペレーティングシステムのコンポーネントの脆弱性も探されます（発見されます）。



コンポーネントの最新バージョンを使用し、securityfocus.comのようなサイトで新たに発見された脆弱性を監視することは非常に重要です。

10.未確認のリダイレクトと転送

多くの場合、Webアプリケーションはユーザーをあるページから別のページにリダイレクトします。 このプロセスでは、リダイレクトの最終宛先のページを示す不適切にチェックされたパラメーターが使用される場合があります。



適切なチェックを行わないと、攻撃者はこれらのページを使用して、被害者を偽のサイトにリダイレクトすることができます。たとえば、非常によく似たインターフェースや見分けがつかないインターフェースがありますが、クレジットカード情報やその他の機密データを盗みます。



このタイプの脆弱性は、上記の他の多くの脆弱性と同様、入力検証エラーの一種です。

結論の代わりに

OWASP TOP-10の主な種類の脆弱性を一般的な方法で調査し、可能な限り簡単な言語でそれらのことを話そうとしました。また、これらの攻撃ベクトルがビジネスにもたらすリスクを簡単な実例で示しました。



まず、この記事は、インターネットプロジェクトの所有者と若い開発者を対象にしています。 将来の記事では、前述の攻撃ベクトルのそれぞれについて、詳細な技術的詳細と説明的な例、そしてもちろん保護方法を含めて、さらに詳しく説明します。



ビジネスオーナーの方は、ITセキュリティに関連するリスクの理解がより完全になり、次の記事がITプロフェッショナルにとって優れたツールになることを願っています。