TOP＞設計・移行・活用＞ Location:ヘッダの組み立て
脆弱なWebアプリケーション
脆弱なWebアプリケーション

第６回：各種の問題
 著者：セントラル・コンピュータ・サービス  長谷川 武
2005/6/2
前のページ  1  2   3  4  次のページ
Location:ヘッダの組み立て

   プログラムによっては、Location:ヘッダのURLを組み立てるための情報の一部をパラメータとして外部から受け取るようになっているものがある。たとえば、ページを呼び出すURLとして次のようなものがあったとしよう。
page2.php?class=a&type=3&next=page3.php&error=top.html

   これは、ページ「page2.php」の処理が無事成功したら、ページ「page3.php」に、何かエラーが生じたら「top.html」ページへ遷移することをパラメータとして与えているという想定である。

   「page2.php」プログラムからこれらのページへ遷移するには、まずリダイレクトすることを表す301というステータスコードを次のような形でレスポンスの先頭に出力する必要がある。

HTTP/1.1 301 moved permanently

   そして、次のどちらかのLocation:ヘッダを書き出すことで実現する。

Location: http://ドメイン/パス/（パラメータnextの値）
または
Location: http://ドメイン/パス/（パラメータerrorの値）


Location:ヘッダを改ざんする

   問題は、外部から受け取ったパラメータの値がHTTPレスポンスヘッダの中に書き出されるところにある。攻撃者は、「page2.php」プログラムのnextパラメータやerrorパラメータに対して、次の内容に相当する一続きの文字列パラメータを与えて攻撃してくる。

<Cr><Lf>
<Cr><Lf>
HTTP/1.1 200 OK<Cr><Lf>
Date: （現在の日付と時刻）<Cr><Lf>
Content-Type: text/html; charset=UTF-8<Cr><Lf>
Content-Length: （偽の内容のバイト数）<Cr><Lf>
<Cr><Lf>
（偽の内容）

※注： <Cr>と<Lf>はそれぞれ行末を示すためのキャリッジリターン制御コードとラインフィード制御コード（16進数表現で0Dと0A）を表す。

   これは、ヘッダ終了の目印である「<Cr><Lf><Cr><Lf>」（改行2つ）を挿入することによって、Webアプリケーションが返そうとしているHTTPヘッダが終了しているように見せかけ、その後ろにHTTPレスポンスの形をした別の内容を付け加えるものだ。

HTTPレスポンスが分割される
図2：HTTPレスポンスが分割される
（画像をクリックすると別ウィンドウに拡大図を表示します）
   実際の攻撃は、制御コードや特殊記号がエンコードされた次のような一続きの文字列の形で送られる。

next=%0D%0A%0D%0AHTTP%2F1.1+200+OK%0D%0ADate%3A+
（日付と時刻）%0D%0AContent-Type%3A+text%2Fhtml%3B+
charset%3DUTF-8%0D%0AContent-Length%3A+（バイト数）
%0D%0A%0D%0A（偽の内容）

   このようにレスポンスが2つに分裂したところで、このレスポンスは攻撃者自身に返ってくるものだから、このままでは何も起こらない。ところが、この攻撃をプロキシサーバ（企業内部からインターネットへのアクセスを中継するサーバ）の内側から行うと事情は変わってくる。
プロキシサーバのキャッシュを汚染

   この偽のレスポンスをWebサイトのトップページURL等と対応づけてプロキシサーバに記憶させておく。すると、そのプロキシ経由で当該ページへアクセスする人々は全員、偽のページを見せられることになる。

   プロキシサーバは、Webクライアントから送られてくるHTTPリクエストを中継し、WebサーバからHTTPレスポンスを受け取る。このとき、組織内の多くの人々が同一のページを見に行く場合を考慮して、取得したWebサーバのレスポンスをキャッシュに保存する。こうしておけば、以降の同じページへのリクエストに対し、実際のWebサーバにアクセスすることなく迅速にレスポンスを返すことができる。

   このしくみを逆手に取ったのがHTTPレスポンス分割による偽ページ攻撃だ。攻撃者は脆弱なWebアプリケーションを悪用して1つのHTTPリクエストから2つのレスポンスを返させるのに続いて、もう1つHTTPリクエストを送り出す。この第2のリクエストには、そのサイトの中でも多くの人々がアクセスすると考えられるページ、たとえばトップページのURLを仕込む。

   Webアクセスを中継するプロキシサーバは、自分が中継するTCP通信ストリームの中を通過するHTTPリクエストとHTTPレスポンスを対にしてキャッシュに保存しようとする。2つのリクエストが送りだされ、レスポンスの形をしたものも2つ返ってくるので、誤った組み合わせをキャッシュに記録してしまう。

プロキシのキャッシュが汚染される
図3：プロキシのキャッシュが汚染される
（画像をクリックすると別ウィンドウに拡大図を表示します）
   このプロキシサーバを共有している組織内の人々はみな、攻撃者がキャッシュに書き込ませた偽の内容を見せられることになる。

   ここまではLocation:ヘッダを前提に見てきたが、Set-Cookie:ヘッダについてもまったく同様である。それ以外にも、ユーザの入力内容をそのまま埋め込んでHTTPレスポンスヘッダを出力するようなWebアプリケーションがあれば、HTTPレスポンス分割攻撃が成立する。
前のページ  1  2   3  4  次のページ

セントラル・コンピュータ・サービス株式会社
 著者プロフィール
セントラル・コンピュータ・サービス株式会社  長谷川 武
シニア・セキュリティ・スペシャリスト、IPA　非常勤研究員。2002年にはIPA ISEC『セキュア・プログラミング講座』の制作ディレクターをつとめた。これを契機に、現在は勤務先とそのパートナー企業を通じてセキュアプログラミングセミナー／実習／スキル評価テストといった教育サービスを「TRUSNET(R)アカデミー」として提供している。問い合わせE-mail：info@trusnet.com。


INDEX
第6回：各種の問題
  はじめに
Location:ヘッダの組み立て
  JavaScriptによる偽ページ
  その他の話題