willnetの日記

HTTP Response Splitting Attack

14:50

HTTP Response Splitting Attackについて。

「おべんきょ」のための用語集に詳しく書いてあるけど見づらいので、見かけだけ手直しして転載します。

HTTP Response Splitting Attackとは何か

ヘッダー情報などを元に、たとえば言語に基づいて異なるページにリダイレクトさせるようなつくりのWebサイトで悪用される恐れがある手法。攻撃者は不正なリクエストを送り込み、サーバから1つではなく2つのレスポンスを受けるよう仕向ける。この2つめのレスポンスにさらに細工を施すことで、サイトのなりすましを行ったり、被害者のWebブラウザのキャッシュを汚染させたり、クロスサイトスクリプティングを仕掛けたりと、多様な攻撃が可能になるというものだ。

「HTTPレスポンス分割」とは，HTTPレスポンスヘッダーにCR+LFやContent-Length: 0を含めるて一つのHTTPレスポンスを複数のHTTPレスポンスであるように偽装し，ブラウザやProxyのキャッシュに悪意のあるHTTPレスポンスヘッダーを残す攻撃手法である。

これにより，この脆弱性を利用された場合，フィッシング詐欺などの被害が発生する可能性がある。この問題を回避するためには，HTTPレスポンスヘッダーの中にあるCR+LFをサニタイズする必要がある。本バージョンでは，header()関数の内部処理においてこのサニタイズ処理を追加し，安全性を向上させている。

日本語にすると「HTTP 応答分割攻撃」といったところでしょうか (IPA 的には「HTTP レスポンス分割」みたいです)。簡単に言うと、HTTP応答ヘッダに CR+LF やら Content-Length: 0 やらをインジェクションして、ひとつのHTTP 応答が二つの HTTP 応答であるように仕立てる攻撃です。

以下のような感じの応答を捏造します。

HTTP/1.1 302 Found
Conetnt-Type: text/html
Location: http://example.com/
Content-Length: 0

HTTP/1.1 200 OK
Conetnt-Type: text/html

すると、Content-Length: 0 な応答の後にもう一つの HTTP 応答が返ってきているように見えます。ものによっては前者に従ってリダイレクトしつつ、何故か後者の内容をキャッシュしてしまったりすることがあったりするようです。

この攻撃は、HTTP 応答ヘッダに任意の内容がインジェクションできる場合に可能となります。よくあるのは Location: フィールドの値として出力する URL が外部から入力されるシステムで、このサニタイズを怠っているとあっさり成立することがあります。HTTP 応答ヘッダに外部入力を出力する際は、確実に CR+LF をサニタイズしなければなりません。

不正な入力により、サーバのHTTPレスポンスを二つに分割させることで、プロキシやブラウザに対してセキュリティ侵害を起こさせる攻撃

• ブラウザからの入力に基づいてリダイレクトのLocationヘッダを構築するようなWebシステムで発生
• ブラウザやプロキシに偽のコンテンツを送り込み、キャッシュを汚染→ コンテンツ・スプーフィング
• ブラウザに対するクロスサイト・スクリプティング攻撃→ Cookieの取得、改変

対策

• HTTPヘッダとして出力する箇所に「%0d%0a」すなわちCR/LFを入れないようにする
• ユーザ入力文字列を使用時（HTTPヘッダ挿入時）に無害化
  • Locationヘッダ→ レスポンス・スプリッティング
  • Set-Cookieヘッダ→ クロスサイト・スクリプティング
  • 最低限、無害化すべき文字
    • 「%0d%0a」すなわちCR/LF
  • 文字列から削除することが望ましい
  • 適切な文字以外はすべて削除する... ホワイトリスト方式

　HTTP Response Splitting Attack はクロスサイトスクリプティング (XSS) と同様に、web アプリにおける入力値の除染が不十分なことが引金になる。ただし、 XSS は「スクリプトとみなされるような入力」を許容してしまうために発生するが、HTTP Response Splitting Attack は「複数の HTTP レスポンスとみなされるような入力」を許容してしまうために発生する。典型的な例として、

リダイレクトをする web アプリにおいて、 アクセス元 URL をパラメータ (の一部) としてリダイレクトする場合に、パラメータの除染が不十分であると、HTTP Response Splitting Attack に対して脆弱である、とされている。

HTTP Response Splitting Attack を受けると、http proxy サーバ (forward / reverse proxy) 上のキャッシュ，web ブラウザ上のキャッシュ が汚染されてしまうため、これによってフィッシング詐欺などが可能になるという。キャッシュ汚染の例として、Apache 2.0 / Squid 2.4 / IE 6.0 SP1 での事例が述べられている。

　HTTP Response Splitting Attack への対応としては、以下が挙げられている (p.24):

• web アプリ開発者は、入力値の除染、特に CR/LF の削除を行う。
• web アプリエンジンベンダーは、HTTP レスポンスヘッダに CR/LF が含まれない (RFC2616 に従う) よう保障する。
• proxy ベンダーは、複数の仮想ホストに対する TCP コネクションの共有を行わないようにする。またリクエスト host ヘッダの処理をきちんと行う。
• client ベンダーは、forward proxy 経由でリクエストを送る際は、異なる仮想ホストに対しては異なる TCP コネクションを使う。