Webアプリケーション攻撃第2回: インジェクション系後編

2024-06-10

本記事は、インジェクション系攻撃手法紹介の後編です。今回は次の2つのインジェクション系攻撃について解説していきます。

HTTPヘッダ・インジェクション
メールヘッダ・インジェクション

HTTPヘッダ・インジェクション

HTTPヘッダ・インジェクションは、攻撃者がウェブサーバーからのレスポンスヘッダに不正なコードや文字列を注入することで発生します。これにより、攻撃者は様々な悪意のある行為を行うことが可能になります。

一般的なものだと、攻撃者は、改行文字(CRLF)を利用して新たなHTTPヘッダを追加し、レスポンスヘッダの内容を改ざんします。HTTPのレスポンスヘッダはテキスト形式で1行に1つのヘッダが定義され、各ヘッダは改行で区切られます。攻撃者が改行文字を挿入することで、新しいHTTPレスポンスヘッダを追加し、悪意のあるヘッダ情報を返信させることが可能になります。

具体的な被害には以下のものが考えられます。

リダイレクト攻撃: 攻撃者がレスポンスヘッダに不正なリダイレクト先のURLを挿入することで、ユーザーを不正なサイトにリダイレクトさせることができます。これにより、ユーザーが偽のログインページや詐欺サイトに誘導され、機密情報を漏洩させる可能性があります。
クッキーの操作: 攻撃者がレスポンスヘッダに不正なクッキー情報を挿入することで、ユーザーのセッションを乗っ取ることができます。これにより、攻撃者はユーザーのアカウントに不正アクセスし、機密情報を盗み取ることが可能になります。
キャッシュの操縦: 攻撃者がレスポンスヘッダにキャッシュ制御命令を挿入することで、クライアントやプロキシサーバーのキャッシュを操ることができます。これにより、攻撃者は偽のコンテンツをキャッシュに保存させ、ユーザーに偽の情報を提供することが可能になります。

HTTPヘッダ・インジェクションが成功すると、攻撃者は悪意のあるコードをサーバーからのレスポンスに挿入し、ユーザーに対する攻撃を行うことができます。これにより、機密情報の漏洩やユーザーのセッションの乗っ取りなどの被害が発生する可能性があります。

HTTPヘッダ・インジェクションの攻撃手法

HTTPヘッダ・インジェクションの主な原因は、ウェブアプリケーションが入力値を適切に検証またはエスケープせずに、そのままレスポンスヘッダーに挿入してしまうことです。攻撃者はこの入力を利用して、不正なヘッダーを注入し、ウェブサーバーがその内容を解釈するように仕向けます。

例えば、URLのクエリストリングスの文字列から、リダイレクト先を決めるプログラムがあったとします。

http://example.bloomblock.net/?redirect-url=http://target.bloomblock.net/

この例では、クエリストリングスのredirect-urlで指定されているurlにリダイレクトされる、といった動作をイメージしています。

このとき、脆弱性があるプログラムにて、以下のようなクエリストリングスを指定したらどうなるでしょうか。

http://example.bloomblock.net/?redirect-url=http://target.bloomblock.net/%0d%0aLocation: http://vulnerability.bloomblock.com/

改行コードを示すパーセントエンコード文字列%0d%0aがあるため、このプログラムでは以下のように二行のLocationヘッダを生成されます。

Location: http://target.bloomblock.net/
Location: http://vulnerability.bloomblock.com/

Webサーバによっても挙動は異なりますが、複数行のLocationヘッダが存在する場合、最後のLocationヘッダのみレスポンスとして応答するため、クライアントは攻撃者が用意した罠サイトに誘導される可能性があります。

HTTPヘッダ・インジェクションの対策

HTTPヘッダ・インジェクションを防ぐためには、入力値の検証とエスケープが重要です。また、そもそも外部からのパラメータをHTTPレスポンスヘッダとして出力しない、という対策も有用です。

入力値の検証: サーバー側で受信したHTTPリクエストのヘッダーを検証し、改行文字などの不正な文字が含まれている場合は、リクエストを拒否します。
エスケープ処理の実施: クッキーに含まれる値をパーセントエンコードすることで、不正な改行文字の挿入を防ぎます。
外部パラメータを出力しない: リダイレクトであれば、URLを直接指定するのではなく、番号などで間接的に指定します。また、クッキーの場合は、アプリケーション側で作成するセッション変数などを用いれば、外部入力への依存を下げることができます。

メールヘッダ・インジェクション

メールヘッダーインジェクションは、電子メールの送信時に悪意のあるユーザーがメールのヘッダー部分に不正なデータを挿入することによって、攻撃者がメールの内容や挙動を操作する脆弱性です。

電子メールの構成についても少し触れておきます。HTTPと似ており、ヘッダとボディの二つの主要な部分から構成されます。

ヘッダー (Header): 送信者のメールアドレス、受信者のメールアドレス、件名、送信日時などの情報を含みます。また、メールの送信経路や転送された際の情報などもヘッダーに含まれます。通常はテキスト形式で、”From”, “To”, “Subject”, “Date”などのフィールドとその値から構成されます。
ボディ (Body): 実際のメッセージ本文や添付ファイルなどのコンテンツを含む部分です。ヘッダー部分で指定された形式に従って構成され、例えば、”Content-Type”ヘッダーの値によって、テキスト、HTML、画像などのコンテンツの種類が指定されます。

ヘッダとボディは改行で分離されます。

メールヘッダ・インジェクションの具体的な被害には以下のものが考えられます。

スパムやフィッシング: 攻撃者が不正なヘッダを挿入して、受信者を騙すための偽の情報を表示することができます。
セキュリティの脅威: 攻撃者がメールのヘッダを改ざんして、悪意のあるリンクや添付ファイルを隠すことができます。
メールの不正なルーティング: 攻撃者が不正なヘッダを挿入して、メールを間違った受信者に送信することができます。

メールヘッダ・インジェクションの攻撃手法

メールヘッダ・インジェクションの主な原因は、メールサーバーやクライアントが入力値を適切に検証せずに、そのままヘッダに挿入することです。例えば、以下のような問い合わせフォームがあったとします。「起票者」の項目からメールヘッダーのFrom情報を、「問い合わせ内容」の項目からメールボディである本文の情報を構成するプログラムです。

この時、「起票者」の項目に以下を入力します。

脆弱性が存在する場合、「起票者」の項目にBccとしてメールアドレスを加えることで、意図された受信者に加えて、Bccで指定したアドレスに対しても電子メールを配信できます。この手口を使い、匿名で大量のメッセージを送信することや、受信者がこれらのメッセージが信頼できるソースから発信されていると信じるようなフィッシング・メールを送信する可能性もあります。

上記はメールヘッダの例でしたが、例えば、以下のように「起票者」の項目に改行を含むことで、メール本文を改ざんすることもできる可能性があります。

これは、メールにおいても、HTTPと同様、改行に特別な意味を持つことに起因します。メールヘッダとボディは改行で分離されているため、本来、この例の「起票者」の項目はメールヘッダの情報となることが想定されています。しかし、改行を挿入し、メールボディとして誤認識させることで、改ざんを行います。

メールヘッダ・インジェクションの対策

メールヘッダ・インジェクションを防ぐための対策としては、入力値の検証が重要です。また、メールのメッセージ形式が、ヘッダとボディを改行で区切るというHTTPと似た形式であることを理解しておくことも大切です。

入力値の検証: メールヘッダ・インジェクションの原因は、改行を含めることで、新たなヘッダや本文を挿入されることです。メール送信時に改行文字を検証することで、脆弱性の対策となります。
外部パラメータを含めない: 外部からのパラメータをメールヘッダに含めなければ、メール・ヘッダインジェクションの脆弱性はそもそも起き得ません。