第8章 5.クライアントサイドマッシュアップ：リクエスト強要攻撃による善意のAPIへの侵害

本ページの情報は2007年6月時点のものです。
記載の資料は資料公開当時のもので、現在は公開されていないものも含みます。

「リクエスト強要攻撃」

リクエスト強要攻撃は、罠のコンテンツを用いてブラウザを誘導し、ユーザの意思に反した HTTPリクエストを善意のWebサーバへ送信させる攻撃である。ユーザ本人の望まない「更新系」のトランザクションが投入され、被害が生じる。

これまで注意深いWebアプリケーション開発者の間では、サーバにおける「更新系」の処理について「リクエスト強要攻撃」が警戒され、対策がとられてきた。対策が「更新系」に限定されていたのは、従来型のWebアプリケーションでは「参照系」のトランザクションが投入されても攻撃者がその処理結果を入手することが困難であり、あまり実害が無かったからである。

しかし、クライアントサイドマッシュアップにおいては「非同期の他源泉リクエスト」という手法が多用され、その状況においては「更新系」の処理のみならず、「参照系」の処理についても「リクエスト強要攻撃」への警戒と対策が必要になってきた。

「非同期の他源泉リクエスト」

本稿で「非同期の他源泉リクエスト」と呼ぶのは次のような動作を実現するプログラミング手法のことである──

「非同期の他源泉リクエスト」複数の方法

「非同期の他源泉リクエスト」の実現方法には、これまで次の 5つが知られている。

• JSONP ── JSON 形式の文字列データを引数にとる関数呼び出しの形態の JavaScript ソースコードを、動的に <script> タグを生成して他源泉からロードする方法
• iframeコール ── 親・子・孫三代の iframe 構造を用い、他源泉へのリクエスト送信 (子) と源泉間のデータ受け渡し (孫) を分担して行う方法
• iframe + postMessage ── HTML5 の postMessage を用いて iframe 内外のデータ受け渡しを行う方法
• Webワーカ + importScripts ── HTML5 の Webワーカ と、Webワーカ に備わる importScripts とを用いて JavaScript コードを他源泉からロードする方法
• XMLHttpRequest level 2 ── 他源泉へリクエストを出せるよう拡張された XMLHttpRequest 組み込みオブジェクトを用いる方法（Microsoft Internet Explorer においては名前の異なる XDomainRequest という組み込みオブジェクトを用いる）

他源泉におけるリクエスト強要攻撃

5種類の「非同期の他源泉リクエスト」方法のそれぞれについて、サーバの「参照系」処理に対する「リクエスト強要攻撃」が情報漏えいを引き起こす模様を想定してみる。

(1) リクエスト強要攻撃—JSONP

JSONP におけるリクエスト強要攻撃は下記の図のように行われる。

善意のサーバ (サーバB) のセッションが Cookie で維持されている状況下で、悪意のサーバのコンテンツが正常系と同様の JSONP 手法を用い、サーバBからデータを不正に入手する。

ここでは次を仮定している。

• ブラウザがサーバBの有効なセッションID の Cookie をもっている

(2) リクエスト強要攻撃—iframeコール

iframeコールにおけるリクエスト強要攻撃は下記の図のように行われる。

善意のサーバ (サーバB) のセッションが Cookie で維持されている状況下で、悪意のサーバのコンテンツが正常系と同様の iframe コール手法を用い、サーバB からデータを不正に入手する。

ここでは次を仮定している。

• ブラウザが、サーバB の有効なセッションIDのCookieをもっている（XHR1 でも Cookie が飛ぶ）

• サーバBの iframeコンテンツに対して孫iframe にロードさせるコンテンツのURIをパラメタで指定できるが、その妥当性に関するサーバBにおける検査が甘い

(3) リクエスト強要攻撃—iframe+postMessage

iframe+postMessageにおけるリクエスト強要攻撃は下記の図のように行われる。

善意のサーバ（サーバB）のセッションが Cookie で維持されている状況下で、iframe 子要素が親要素へ postMessage でデータを受け渡してくるのをそのまま受け取り、悪意のサーバがデータを不正に入手する。

ここでは次を仮定している。

• ブラウザが、サーバBの有効なセッションIDの Cookieをもっている（XHR1 でも Cookie が飛ぶ）

(4) リクエスト強要攻撃—ワーカ+importScripts

ワーカ+importScripts におけるリクエスト強要攻撃は下記の図のように行われる。

善意のサーバ（サーバB）のセッションが Cookie で維持されている状況下で、悪意のサーバのコンテンツが importScripts を使用して、サーバB からデータを不正に入手する。

ここでは次を仮定している。

• ブラウザが、サーバB の有効なセッションID の Cookie をもっている（なお、ここでは XHR1 は使えない）

(5) リクエスト強要攻撃—XHR2

XHR2 におけるリクエスト強要攻撃は下記の図のように行われる。

善意のサーバ（サーバB）のセッションが Cookie で維持されている状況下で、悪意のサーバのコンテンツが XHR2 を使用して、サーバB からデータを不正に入手する。

ここでは次を仮定している。

• ブラウザが、サーバB の有効なセッションID の Cookieをもっている
• サーバB における Origin:リクエストヘッダの検査が甘い
• 悪意のサーバに対しても、「Access-Control-Allow-Origin: リクエストしてきたサーバ」および「Access-Control-Allow-Credentials: true」のレスポンスヘッダが発行される
  

リクエスト強要攻撃への耐性

どのリクエスト手段もリクエスト強要攻撃の餌食になり得る。「非同期の他源泉リクエスト」の 5つの方法それぞれのリクエスト強要攻撃への耐性を一覧にすると次のようになる 。

XHR2

XHR2（XMLHttpRequest level 2）は「非同期の他源泉リクエスト」の 5つの方法の中でも比較的強固である。XHR2 の通信上の特徴は、HTTPリクエストおよびレスポンスの中で次のようなヘッダを用いるというものである。

• Origin: origin　リクエストヘッダ
• Access-Control-Allow-Origin: origin　レスポンスヘッダ
• Access-Control-Allow-Credentials: boolean　レスポンスヘッダ
  (これら以外にも複数種類の Access-Control-* レスポンスヘッダが存在する)

上記のヘッダ群を用いて、XHR2 はセキュリティ確保のための振る舞いをする。主なものは次の3つである。

• JavaScript コードが要求してきたものが他源泉へのアクセスであることを自動判別し、XHR 2 はリクエストに
  　Origin: origin
  リクエストヘッダを含める。ここに、origin　は現在の JavaScript コードの源泉 (出身サーバ) を表す URI である。これは、リクエストが他源泉リクエストであることと、どの源泉からのリクエストであるかをサーバへ知らせるものである。
• サーバが所定の
  　Access-Control-Allow-Origin: origin
  レスポンスヘッダを返して来なければ、XHR2 はレスポンスデータを JavaScript コードへ引き渡さない
• Cookie を含むリクエストに対して、サーバが
  　Acess-Control-Allow-Credentials: true
  レスポンスヘッダを返して来なければ、XHR2 はレスポンスデータを JavaScript コードへ引き渡さない

XHR2 を用いた他源泉リクエスト

XHR2 を用いた他源泉リクエストの通信の流れを次に示す。

XHR2 を突破できるケース

セキュリティの配慮がある XHR2 であっても、次のような条件が成立する場合にはリクエスト強要攻撃が成立し得る。

• クライアントから送られてきた　Origin: origin　リクエストヘッダに対して、サーバが必ず　Access-Control-Allow-Origin: origin　レスポンスヘッダを返すようになっている。かつ、
• サーバが　Access-Control-Allow-Credentials: true　レスポンスヘッダを発行するとともに、Cookie を用いたセッション維持を行っている。