HOME >> 情報セキュリティ >> 調査・研究報告書 >> 情報セキュリティ技術動向調査（2011 年下期） >> 5. 非同期の他源泉リクエストと新たな脅威
情報セキュリティ技術動向調査（2011 年下期）
5. 非同期の他源泉リクエストと新たな脅威
長谷川 武
5.1. 新しい侵害パターン
リクエスト強要（CSRF）攻撃[1]はこれまで、更新系トランザクションについて警戒を要するものであると、慎重なWebアプリケーション開発者の間で認識されてきた。しかし、Ajax [2]技術および他源泉へのリクエスト（Cross-origin Request）[3]を用いたWebアプリケーションでは、参照系トランザクションに関しても攻撃を警戒する必要が生じている。
図1：リクエスト強要──従来の侵害のかたち
図2：リクエスト強要──新しい侵害パターン
5.2. リクエスト強要攻撃（Cross-site Request Forgery Attack）
(1) 攻撃にはCookieが関係
リクエスト強要攻撃が成立する要因には、主にCookie [4]の仕組みが関係している。Cookieは、一度ブラウザによって保持されると、特定のサーバへ向けたHTTPリクエストには毎回それが添付されるという性質をもつ。
リクエスト強要攻撃は、Cookieによるセッション維持が成立している状況に悪意の第三者が便乗して、ユーザ本人の意思に反したトランザクションを投入するよう、ブラウザを誘導する攻撃である。
図3：リクエスト強要攻撃は、セッション維持のCookieに便乗する
(2) 攻撃成立の詳細
リクエスト強要攻撃は次の図のように進行する。
図4：リクエスト強要攻撃成立の詳細
5.3. 非同期の他源泉リクエスト（Asynchronous Cross-origin Request）
昨今はいわゆるAjax [2]と呼ばれる、ひと組のJavaScriptが長時間ブラウザ上に常駐してその中でサーバアクセスを行うタイプのWebアプリケーションが増えてきた。このAjaxの中でも、自分の出身サーバとは異なるサーバへのリクエスト、すなわち他源泉リクエスト（Cross-origin Request）[3] を発行するものも出てきた。
(1) 非同期の他源泉リクエスト
「非同期の他源泉リクエスト」を、ここでは次のように定義する。
- ブラウザ上のJavaScriptコード内から、
- そのJavaScriptコードの出身サーバ（「源泉」）とは異なるWebサーバ（別の「源泉」）へHTTPリクエストを送ってレスポンスを受け取り、
- その後もJavaScriptコードが動作を継続すること
(2) 「非同期の他源泉リクエスト」複数の方法
非同期の他源泉リクエストを実現する方法には次のような複数のものが知られている。
図5：非同期の他源泉リクエストの5種類の方法
5.4. 他源泉におけるリクエスト強要攻撃
上記の「非同期の他源泉リクエスト」のどの方法についても、リクエスト強要攻撃が成立する状況がありうる。
(1) 攻撃が成立するシナリオ
非同期の他源泉リクエストの上記5種類の方法のそれぞれについてリクエスト許容攻撃が成立するシナリオを想定すると、次のようになる。
- JSONP [5] に対して攻撃が成立するシナリオ
図6：JSONPへの攻撃
-
・ ブラウザがサーバBの有効なセッションIDのCookieをもっている
- iframeコール[6]に対して攻撃が成立するシナリオ
図7：iframeコールへの攻撃
-
・ ブラウザが、サーバBの有効なセッションIDのCookieをもっている（XHR 1でもCookieが飛ぶ）
・ サーバBのiframeコンテンツに対して孫iframeにロードさせるコンテンツのURIをパラメタで指定できるがその検査が甘い
- iframe+postMessage [7]に対して攻撃が成立するシナリオ
図8：iframe+postMessageへの攻撃
-
・ ブラウザが、サーバBの有効なセッションIDのCookieをもっている（XHR 1でもCookieが飛ぶ）
- Webワーカ+importScripts [8]に対して攻撃が成立するシナリオ
図9：Webワーカ+importScriptsへの攻撃
-
・ ブラウザが、サーバBの有効なセッションIDのCookieをもっている（なお、ここではXHR 1は使えない）
- XMLHttpRequest level 2（XHR 2）[9]に対して攻撃が成立するシナリオ
図10：XHR 2への攻撃
- ・ ブラウザが、サーバBの有効なセッションIDのCookieをもっている
・ サーバBにおける Origin:リクエストヘッダの検査が甘い
・ 悪意のサーバに対しても、「Access-Control- Allow-Origin: リクエストしてきたサーバ」および「Access-Control- Allow-Credentials: true」のレスポンスヘッダが発行される
(2) リクエスト強要攻撃への耐性
これらを要約すると、攻撃が成立するための条件が他よりも厳しいことから、XHR 2は比較的攻撃に耐性があるということがいえる。
図11：5種類の方法の、リクエスト強要攻撃への耐性
5.5. XMLHttpRequest level 2（XHR 2）
ここでは、XHR 2の動作をもう少し掘り下げて議論する。
(1) XMLHttpRequest level 2（XHR 2）の通信
XHR 2は次のようなHTTP通信上の特徴をもつ。[10]
- Origin: リクエストヘッダを送信する
- Access-Control-Allow-Origin: レスポンスヘッダをサーバから受信することを期待している（これ以外にも複数種類の Access-Control-* ヘッダがある）
XHR 2 は、サーバが所定の Acess-Control-Allow-Origin: ヘッダを返さなければ、レスポンスデータをJavaScriptコードへ引き渡さない等の制約を課すことで、セキュリティの確保に配慮している。
(2) XHR 2 を用いた他源泉リクエスト
XHR 2を用いた他源泉リクエストは次のように進行する。
図12：XHR 2を用いた他源泉リクエスト
(3) リクエスト強要──XHR 2を突破できるケース
リクエスト強要攻撃がXHR 2を突破するためには次のふたつの条件が成立している必要がある。
- 条件1： データ供給サイトは、他源泉リクエストを受け付ける際のOrigin: リクエストヘッダの検査が厳しくない。送ったオリジンが含まれるAccess-Control-Allow-Origin: レスポンスヘッダもが返される
- 条件2： データ供給サイトでは、Cookieを用いたセッション維持が行われている。そのため、サイトからは、Access-Control-Allow-Credentials: true レスポンスヘッダが返される。
図13：XHR 2の他源泉リクエストにおけるリクエスト強要攻撃
5.6. 他源泉リクエスト状況におけるリクエスト強要対策
他源泉リクエストにおけるリクエスト強要対策にあたっては、次の点を考慮する。
(1) セッション対策／トークン対策
- セッションを用いない（できるだけ）
- セッション維持にCookieを用いない（Basic認証、Digest認証も[11]）
→ 対策例1 - 他者が推測困難なトークンの発行・照合
→ 対策例2 - OAuth [12] のアクセストークンの利用
(2) XHR 2
- 他源泉リクエスト発行手段には XHR 2 を選ぶ（IE 8 では XDR）
- サーバでは Origin: を厳密に検査
- Access-Control-Allow-Origin: の発行を必要最小限に
(3) そもそも、他源泉リクエストの使用を必要最小限に
図14：対策例1 セッションIDをPOSTデータで搬送
図15：対策例2 CookieによるセッションIDのほかにトークンを照合
5.7. まとめ
- リクエスト強要攻撃は、「更新系」処理のみならず、「参照系」処理でも警戒する
- 非同期の他源泉リクエストには、複数の実装方法がある
- どの実装方法も、リクエスト強要攻撃の餌食にできる
- XHR 2は、他の実装方法よりも比較的強固である
- 他源泉リクエスト状況におけるリクエスト強要対策は、セッション対策 + XHR 2 の慎重な利用である
以上
参考文献