1. ウェブアプリケーションのセキュリティ実装
1.7 HTTP ヘッダ・インジェクション
1.7 HTTP ヘッダ・インジェクション
- 任意の Cookie 発行
Set-Cookie ヘッダを注入された場合、任意の Cookie が発行され、利用者のブラウザに保存さ れる可能性があります。
- キャッシュサーバのキャッシュ汚染
複数のレスポンスに分割し、任意のレスポンスボディをリバースプロキシ等にキャッシュさせるこ とにより、キャッシュ汚染21（ウェブページの差し替え）を引き起こし、ウェブページの改ざんと同じ 脅威が生じます。この攻撃を受けたウェブサイトにアクセスする利用者は、この差し替えられた偽 のウェブページを参照し続けることになります。クロスサイト・スクリプティングのように、攻撃を受 けた直後の本人のみが影響を受ける場合に比べ、キャッシュ汚染による脅威は、影響を受ける対 象が広く、また永続的であることが特徴です。
21 HTTP レスポンス分割によるキャッシュ汚染については、Watchfire 社より次の論文が公開されています。
Watchfire： HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics http://www.watchfire.com/jp/securityzone/whitepapers.asp
この論文で挙げられている脅威の一部には、プロキシサーバやウェブサーバ製品の脆弱性を原因とするものもありま す。これら製品の脆弱性については、同様の脅威をもたらす、「HTTP Request Smuggling（※1）」脆弱性および 「HTTP Response Smuggling（※2）」脆弱性についても注意してください。
※1Watchfire： 「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 が届出を受け、同脆弱 性の対策が施されたソフトウェア製品の例です。
・複数のサイボウズ製品における HTTP ヘッダ・インジェクションの脆弱性
http://jvndb.jvn.jp/contents/ja/2007/JVNDB-2007-000814.html
・CGI RESCUE 製「WebFORM」における HTTP ヘッダ・インジェクションの脆弱性
http://jvndb.jvn.jp/contents/ja/2007/JVNDB-2007-000085.html
■ 根本的解決
1)-1 ヘッダの出力を直接行わず、ウェブアプリケーションの実行環境や言語に用意されているヘッダ 出力用 API を使用する
解説 これは、HTTP レスポンスヘッダの注入攻撃に悪用される「改行コード」を適切に処理 する実装です。
ウェブアプリケーションの実行環境によっては、Content-Type フィールドをはじめとす る HTTP レスポンスヘッダを、プログラムで直接出力するものがあります。このような環 境で Location フィールド等を直接出力する場合に、フィールド値に式の値をそのまま 出力すると、外部から与えられた改行コードが余分な改行として差し込まれることになり ます。HTTP ヘッダは改行によって区切られる構造となっているため、これを許すと、任 意のヘッダフィールドや任意のボディを注入されたり、レスポンスを分割されたりする原 因となります。ヘッダの構造は継続行が許されるなど単純なものではありませんので、
実行環境に用意されたヘッダ出力用の API を使用することをお勧めします。
ただし、実行環境によっては、ヘッダ出力 API が改行コードを適切に処理しない脆弱 性が指摘されているものもあります。その場合には修正パッチを適用するか、適用でき ない場合には、次の 1)-2 または 2)の対策をとります。
1.7 HTTP ヘッダ・インジェクション 1)-2 改行コードを適切に処理するヘッダ出力用 API を利用できない場合は、改行を許可しないよう、
開発者自身で適切な処理を実装する
解説 これは、根本的解決 1)-1 で取り上げたヘッダ出力用 API をもたない実行環境や言 語を利用している場合か、あるいはその API 自体に脆弱性が存在し、それが修正され ていない場合などに実装すべき内容です。
例えば、改行の後に空白を入れることで継続行として処理する方法や、改行コード以 降の文字を削除する方法、改行が含まれていたらウェブページ生成の処理を中止する 方法などが考えられます。
■ 保険的対策
2) 外部からの入力の全てについて、改行コードを削除する
解説 これは、上記根本的解決を実施できない場合や、対策に漏れが生じる懸念がある場 合にセーフティネットとなる対策です。
外部からの入力の全てについて、改行コードを削除します。あるいは、改行コードだ けでなく、制御コード全てを削除してもよいかもしれません。ただし、ウェブアプリケーシ ョンが、TEXTAREA の入力データなど、改行コードを含みうる文字列を受け付ける必要 がある場合には、一律に全ての入力に対して処理を行うと、そのウェブアプリケーション が正しく動作しなくなるため、注意が必要です。
以上の対策により、HTTP ヘッダ・インジェクション攻撃に対する安全性の向上が期待できます。HTTP ヘッダ・インジェクションに関する情報については、次の資料も参考にしてください。
参考 URL
IPA： 知っていますか？脆弱性 (ぜいじゃくせい) 「7. HTTP ヘッダ・インジェクション」
http://www.ipa.go.jp/security/vuln/vuln_contents/hhi.html http://www.ipa.go.jp/security/vuln/vuln_contents/hhi_flash.html
IPA： セキュア・プログラミング講座 「HTTP レスポンスによるキャッシュ偽造攻撃対策」
http://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/603.html