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

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

- 任意の Cookie 発行

Set-Cookie ヘッダを注入された場合、任意の Cookie が発行され、利用者のブラウザに保存さ れる可能性があります。

- キャッシュサーバのキャッシュ汚染

複数のレスポンスに分割し、任意のレスポンスボディをリバースプロキシ等にキャッシュさせる ことにより、キャッシュ汚染³⁰（ウェブページの差し替え）を引き起こし、ウェブページの改ざんと同じ 脅威が生じます。この攻撃を受けたウェブサイトにアクセスする利用者は、この差し替えられた偽 のウェブページを参照し続けることになります。クロスサイト・スクリプティング攻撃のように、攻撃 を受けた直後の本人のみが影響を受ける場合に比べ、キャッシュ汚染による脅威は、影響を受け る対象が広く、また永続的であることが特徴です。

30 HTTP レスポンス分割によるキャッシュ汚染については、Watchfire 社より次の論文が公開されています。

Watchfire： HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics http://www-01.ibm.com/support/docview.wss?uid=swg27019020

この論文で挙げられている脅威の一部には、プロキシサーバやウェブサーバ製品の脆弱性を原因とするものもありま す。これら製品の脆弱性については、同様の脅威をもたらす、「HTTP Request Smuggling（※1）」脆弱性および 「HTTP Response Smuggling（※2）」脆弱性についても注意してください。

※1 Watchfire： 「HTTP Request Smuggling」 http://www.watchfire.com/jp/securityzone/whitepapers.asp （リンク切れ）

※2 Securityfocus： 「HTTP Response Smuggling」 http://www.securityfocus.com/archive/1/425593/30/0/threaded 分割されたレスポンスがキャッシュサーバにキャッシュされ、こ のサイトの利用者が差し替えられた偽のウェブ ページを閲覧してしまう可能性がありま す。

HTTPレスポンス分割とキャッシュ汚染

１．レスポンスを分割し、偽のページBを キャッシュさせる攻撃リクエストを送信

キャッシュサーバ

３．キャッシュが汚染さ れているこ とを知らず に、

ページBをリクエスト

ページBとして キャッシュ

２．一つのHTTPレスポンスに、

複数のHTTPレスポンスが存 在するように出力

レスポンスA レスポンスB 攻撃リクエスト

ページ B ページ B

偽のページ B

キ ャッシュさ れていた本来の ページBが差し替えられる 悪意のある人

利用者

偽のページB を閲覧

HTTPヘッダインジェク ションの脆弱性がある ウェブアプリケーション ウェブサイト

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

■ 注意が必要なウェブサイトの特徴

運営主体やウェブサイトの性質を問わず、HTTP レスポンスヘッダのフィールド値（Location ヘッダ、

Set-Cookie ヘッダ等）を、外部から渡されるパラメータの値から動的に生成する実装のウェブアプリケー ションに注意が必要な問題です。Cookie を利用してログインのセッション管理を行っているサイトや、サイ ト内にリバースプロキシとしてキャッシュサーバを構築しているサイトは、特に注意が必要です。

■ 届出状況

HTTP ヘッダ・インジェクションの脆弱性の届出がウェブサイトの届出全体に占める割合は数パーセン トと多くはありません。しかしながらこれらの脆弱性については受付開始当初から継続的に届出を受け ています。下記は、IPA が届出を受け、同脆弱性の対策が施されたソフトウェア製品の例です。

・「Pebble」における HTTP ヘッダ・インジェクションの脆弱性 http://jvndb.jvn.jp/jvndb/JVNDB-2012-000099

・「Cogent DataHub」における HTTP ヘッダ・インジェクションの脆弱性 http://jvndb.jvn.jp/jvndb/JVNDB-2012-000002

・「Active! mail 6」における HTTP ヘッダ・インジェクションの脆弱性 http://jvndb.jvn.jp/jvndb/JVNDB-2010-000050

■ 根本的解決

ウェブアプリケーションの実行環境によっては、Content-Type フィールドをはじめとする HTTP レス ポンスヘッダを、プログラムで直接出力するものがあります。このような場合に、フィールド値に式の値 をそのまま出力すると、外部から与えられた改行コードが余分な改行として差し込まれることになりま す。HTTP ヘッダは改行によって区切られる構造となっているため、これを許すと、任意のヘッダフィー ルドや任意のボディを注入されたり、レスポンスを分割されたりする原因となります。ヘッダの構造は 継続行が許される等単純なものではありませんので、実行環境に用意されたヘッダ出力用の API を使 用することをお勧めします。

ただし、実行環境によっては、ヘッダ出力 API が改行コードを適切に処理しない脆弱性が指摘され ているものもあります。その場合には修正パッチを適用するか、適用できない場合には、次の 7-(i)-b または 7-(ii) の対策をとります。

例えば、改行の後に空白を入れることで継続行として処理する方法や、改行コード以降の文字を削

☞ ヘッダの出力を直接行わず、ウェブアプリケーションの実行環境や言語に用意されて いるヘッダ出力用 API を使用する。

☞ 改行コードを適切に処理するヘッダ出力用 API を利用できない場合は、改行を許可 しないよう、開発者自身で適切な処理を実装する。

7-(i)-a

7-(i)-b

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

除する方法³¹、改行が含まれていたらウェブページ生成の処理を中止する方法等が考えられます。

■ 保険的対策

外部からの入力の全てについて、改行コードを削除します。あるいは、改行コードだけでなく、制御コ ード全てを削除してもよいかもしれません。ただし、ウェブアプリケーションが、TEXTAREA の入力デー タ等、改行コードを含みうる文字列を受け付ける必要がある場合には、この対策のように一律に全て の入力に対して処理を行うと、対策を実施したウェブアプリケーションが正しく動作しなくなるため、注 意が必要です。

以上の対策により、HTTP ヘッダ・インジェクション攻撃に対する安全性の向上が期待できます。HTTP ヘッダ・インジェクションの脆弱性に関する情報については、次の資料も参考にしてください。

■ CWE

CWE-113： Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting') http://cwe.mitre.org/data/definitions/113.html

■ 参考 URL

IPA： 知っていますか？脆弱性 (ぜいじゃくせい) 「7. HTTP ヘッダ・インジェクション」

https://www.ipa.go.jp/security/vuln/vuln_contents/hhi.html https://www.ipa.go.jp/security/vuln/vuln_contents/hhi_flash.html

31 3.7 の修正例を参照。

☞ 外部からの入力の全てについて、改行コードを削除する。

7-(ii)