9 つの一般的な Web アプリケーション インジェクション攻撃の種類

Web アプリケーションの問題は、Web アプリケーションが何十億ものインターネット ユーザーに公然と公開されており、その多くが理由は何であれ、そのセキュリティ対策を破ろうとすることです。

インターネットの初期の頃、最も一般的な攻撃方法の 1 つは、基本的で単純な総当たり攻撃でした。通常、ボットはこれらの攻撃を実行します。または、十分な時間に余裕のある人が実行し、ターゲット アプリケーションへのアクセスを許可するものが見つかるまで、無数のユーザー名とパスワードの組み合わせを試しました。

パスワード ポリシー、ログイン試行の制限、キャプチャのおかげで、ブルート フォース攻撃はもはや脅威ではありません。しかし、サイバー犯罪者は新しいエクスプロイトを発見し、それを使って新しいタイプの攻撃を実行することを好みます。遠い昔、彼らは、アプリケーションや Web ページ上のテキスト フィールドが悪用される可能性があることを発見しました。そのテキスト フィールドに予期しないテキストを入力 (または挿入) することで、アプリケーションに想定外の動作を強制することができます。このようにして、いわゆる注射攻撃が現場に入ってきました。

インジェクション攻撃は、ユーザー名とパスワードを知らずにアプリケーションにログインするだけでなく、個人情報、機密情報、機密情報を漏洩したり、サーバー全体をハイジャックしたりするためにも使用される可能性があります。そのため、これらの攻撃は Web アプリケーションだけでなく、それらのアプリケーション上にデータが存在するユーザー、さらには最悪の場合、接続されている他のアプリケーションやサービスに対しても脅威となるのです。

コードインジェクション

コードインジェクションは、最も一般的なタイプのインジェクション攻撃の 1 つです。攻撃者が Web アプリケーションで使用されるプログラミング言語、フレームワーク、データベース、またはオペレーティング システムを知っている場合、テキスト入力フィールドを介してコードを挿入し、Web サーバーに意図した動作を強制することができます。

このようなタイプのインジェクション攻撃は、入力データの検証が不足しているアプリケーションで発生する可能性があります。テキスト入力フィールドにユーザーが好きなものを入力できる場合、アプリケーションが悪用される可能性があります。これらの攻撃を防ぐには、アプリケーションはユーザーが入力できる入力を可能な限り制限する必要があります。

たとえば、予想されるデータの量を制限したり、データを受け入れる前にデータ形式をチェックしたり、許可される文字のセットを制限したりする必要があります。

コード インジェクションの脆弱性は、さまざまな種類のコンテンツを使用して Web アプリケーションのテキスト入力をテストするだけで簡単に見つけることができます。脆弱性が発見された場合、悪用するのは中程度に困難です。しかし、攻撃者がこれらの脆弱性のいずれかを悪用した場合、その影響には機密性、完全性、可用性、またはアプリケーション機能の喪失が含まれる可能性があります。

SQLインジェクション

コード インジェクションと同様の方法で、この攻撃は SQL スクリプト (クエリ操作を実行するためにほとんどのデータベースで使用される言語) をテキスト入力フィールドに挿入します。スクリプトはアプリケーションに送信され、データベース上で直接実行されます。その結果、攻撃者はログイン画面を通過したり、データベースから機密データを直接読み取る、データベース データを変更または破壊する、データベース上で管理操作を実行するなど、より危険な行為を実行する可能性があります。

PHP および ASP アプリケーションは、機能インターフェイスが古いため、SQL インジェクション攻撃を受けやすいです。通常、J2EE および ASP.Net アプリは、これらの攻撃に対してより保護されています。 SQL インジェクションの脆弱性が発見された場合、そしてそれらは簡単に発見される可能性がありますが、潜在的な攻撃の規模は攻撃者のスキルと想像力によってのみ制限されます。したがって、SQL インジェクション攻撃の影響は間違いなく大きいです。

コマンドインジェクション

これらの攻撃は、主に入力検証が不十分なために発生する可能性もあります。これらは、攻撃者がプログラミング コードやスクリプトの一部ではなくシステム コマンドを挿入するという点で、コード インジェクション攻撃とは異なります。したがって、ハッカーはアプリケーションのベースとなるプログラミング言語やデータベースで使用される言語を知る必要はありません。ただし、ホスティング サーバーで使用されているオペレーティング システムを知っている必要があります。

挿入されたシステム コマンドは、アプリケーションの権限を持つホスト オペレーティング システムによって実行されます。これにより、サーバー上の任意のファイルの内容の公開、サーバーのディレクトリ構造の表示、ユーザー パスワードの変更などが可能になります。 。

これらの攻撃は、システム管理者がサーバー上で実行されている Web アプリケーションのシステム アクセス レベルを制限することで防ぐことができます。

クロスサイトスクリプティング

アプリケーションが生成する出力内にユーザーからの入力を検証またはエンコードせずに挿入すると、攻撃者が悪意のあるコードを別のエンドユーザーに送信する機会が与えられます。クロスサイト スクリプティング (XSS) 攻撃は、このような機会を利用して、信頼できる Web サイトに悪意のあるスクリプトを挿入し、最終的にはアプリケーションの他のユーザーに送信され、攻撃者の被害者となります。

被害者のブラウザは、信頼すべきではないことを知らずに、悪意のあるスクリプトを実行します。したがって、ブラウザーは、ブラウザーに保存されているセッション トークン、Cookie、または機密情報にアクセスできるようになります。適切にプログラムされていれば、スクリプトは HTML ファイルの内容を書き換えることもできます。

XSS 攻撃は一般に、保存型攻撃と反射型攻撃という 2 つの異なるカテゴリに分類できます。

保存型XSS 攻撃では、悪意のあるスクリプトはターゲット サーバー、メッセージ フォーラム、データベース、訪問者ログなどに永続的に存在します。被害者は、ブラウザが保存された情報を要求したときにスクリプトを入手します。反射型XSS 攻撃では、サーバーに送信された入力を含む応答に悪意のあるスクリプトが反映されます。これは、たとえば、エラー メッセージや検索結果である可能性があります。

XPath インジェクション

このタイプの攻撃は、Web アプリケーションがユーザーから提供された情報を使用して XML データの XPath クエリを構築する場合に発生する可能性があります。これらの攻撃の仕組みは SQL インジェクションに似ています。攻撃者は、XML データの構造を調べるために不正な情報をアプリケーションに送信し、その後、そのデータにアクセスするために再度攻撃します。

XPath は、SQL と同様に、検索する属性を指定できる標準言語です。 XML データに対してクエリを実行するために、Web アプリケーションはユーザー入力を使用して、データが一致する必要があるパターンを設定します。不正な入力を送信すると、パターンが攻撃者がデータに適用したい操作に変わる可能性があります。

SQL の場合とは異なり、XPath では異なるバージョンは存在しません。これは、実装に関係なく、XML データを使用するあらゆる Web アプリケーションで XPath インジェクションを実行できることを意味します。これは、攻撃を自動化できることも意味します。したがって、SQL インジェクションとは異なり、任意の数のオブジェクトに対して実行される可能性があります。

メールコマンドインジェクション

この攻撃方法は、不適切に検証されたユーザー入力を使用して IMAP または SMTP ステートメントを構築する電子メール サーバーやアプリケーションを悪用するために使用される可能性があります。場合によっては、IMAP サーバーや SMTP サーバーには、ほとんどの Web サーバーの場合とは異なり、攻撃に対する強力な保護が備わっていないため、悪用されやすくなる可能性があります。攻撃者はメール サーバーを介して侵入し、キャプチャや限られた数のリクエストなどの制限を回避する可能性があります。

SMTP サーバーを悪用するには、攻撃者が挿入されたコマンドを含むメッセージを送信するための有効な電子メール アカウントが必要です。サーバーが脆弱な場合、攻撃者の要求に応答して、サーバーの制限を無効にし、そのサービスを使用してスパムを送信することが可能になります。

IMAP インジェクションは、メッセージ読み取り機能を利用して、主に Web メール アプリケーションで実行される可能性があります。このような場合、Web ブラウザのアドレス バーにコマンドが挿入された URL を入力するだけで攻撃を実行できます。

CRLF注入

Web フォームの入力フィールドにキャリッジ リターンとライン フィード文字 (CRLF と呼ばれる組み合わせ) を挿入することは、CRLF インジェクションと呼ばれる攻撃手法を表します。これらの目に見えない文字は、HTTP、MIME、NNTP などの多くの従来のインターネット プロトコルで行の終わりまたはコマンドの終わりを示します。

たとえば、HTTP リクエストに CRLF を挿入し、その後に特定の HTML コードを挿入すると、Web サイトの訪問者にカスタム Web ページを送信できます。

この攻撃は、ユーザー入力に適切なフィルタリングを適用しない脆弱な Web アプリケーションに対して実行される可能性があります。この脆弱性は、XSS やコード インジェクションなどの他のタイプのインジェクション攻撃への扉を開き、Web サイトのハイジャックにつながる可能性もあります。

ホストヘッダーインジェクション

多くの Web サイトまたは Web アプリケーションをホストするサーバーでは、常駐 Web サイトまたは Web アプリケーション (それぞれ仮想ホストと呼ばれます) のどれが受信リクエストを処理するかを決定するために、ホスト ヘッダーが必要になります。ヘッダーの値は、どの仮想ホストにリクエストをディスパッチするかをサーバーに指示します。サーバーは無効なホスト ヘッダーを受信すると、通常、それをリストの最初の仮想ホストに渡します。これは、攻撃者がサーバー内の最初の仮想ホストに任意のホスト ヘッダーを送信するために使用できる脆弱性を構成します。

ホスト ヘッダーの操作は一般に PHP アプリケーションに関連しますが、他の Web 開発テクノロジでも実行できます。ホスト ヘッダー攻撃は、Web キャッシュ ポイズニングなどの他の種類の攻撃のイネーブラーとして機能します。その結果、攻撃者による機密操作 (パスワードのリセットなど) の実行が含まれる可能性があります。

LDAPインジェクション

LDAP は、ネットワーク内のリソース (デバイス、ファイル、他のユーザー) の検索を容易にするために設計されたプロトコルです。これはイントラネットにとって非常に便利で、シングル サインオン システムの一部として使用すると、ユーザー名とパスワードの保存に使用できます。 LDAP クエリには、その制御に影響を与える特殊な制御文字が使用されます。攻撃者が LDAP クエリに制御文字を挿入できる場合、LDAP クエリの意図した動作を変更する可能性があります。

繰り返しになりますが、LDAP インジェクション攻撃を可能にする根本的な問題は、ユーザー入力が不適切に検証されることです。ユーザーがアプリケーションに送信するテキストをサニタイズせずに LDAP クエリの一部として使用すると、右側にアスタリスク (*) を使用するだけで、クエリによってすべてのユーザーのリストが取得され、攻撃者に表示される可能性があります。入力文字列内に置きます。

インジェクション攻撃の防止

この記事で見たように、すべてのインジェクション攻撃は、インターネット ユーザーがオープンにアクセスできるサーバーとアプリケーションに向けられています。これらの攻撃を防止する責任は、アプリケーション開発者とサーバー管理者に分散されます。

アプリケーション開発者は、ユーザー入力の誤った検証に伴うリスクを理解し、リスク防止を目的としてユーザー入力をサニタイズするためのベスト プラクティスを学ぶ必要があります。サーバー管理者はシステムを定期的に監査して、脆弱性を検出し、できるだけ早く修正する必要があります。これらの監査をオンデマンドまたは自動で実行するには、多くのオプションがあります。