English
アーカイブ
第8章 3.クライアントサイドマッシュアップ：悪意のAPIサイトからの脅威
公開日：2007年6月28日
独立行政法人情報処理推進機構
セキュリティセンター
本ページの情報は2007年6月時点のものです。
記載の資料は資料公開当時のもので、現在は公開されていないものも含みます。
本節では悪意のAPIサイトによってクライアントが侵害されるシナリオ3つについて論じる。以降ではAPI呼出しの形態を複数に分け、それぞれにおける悪意のAPIサイトからの脅威を考察する。
クライアントサイドマッシュアップの複数の実装形態
ブラウザ上にロードされたコンテンツの内部から直接、サードパーティ（サイトの主催者や利用者とは異なる立場の企業・団体等）のWebサーバのリソースを利用するのがクライアントサイドマッシュアップである。サードパーティのリソースを利用する形態には次の3種類がある。
- サービス呼出し型実装
- サードパーティのWebサービスを、XMLHttpRequest等を用いて呼び出す。最もシンプルな形態である。例えば、TwitterやDropboxのAPI呼出しはこの形態をとる。
- スクリプト取り込み型実装
- サードパーティのWebサイトからスクリプトモジュールをロードして利用する。例えば、Google MapsやGoogle GadgetsのAPI呼出しはこの形態をとる。
- ウィジェット型実装
- サードパーティが用意したユーザインタフェース部品（web widget、ウィジェット）を構成部品として自分のページの中に貼り込む。例えば、Facebookの「いいね！」ウィジェットはこの形態をとる。
これらの実装形態ごとの脅威を次の表に示す。
| 実装形態 | 脅威 |
|---|---|
| (1) サービス呼出し型実装 | 必ずしも高い信頼のおけない「他者の運営するサーバ」から得られた応答の中に攻撃データが含まれる |
| (2) スクリプト取り込み型実装 |
ロードしたスクリプトモジュールの中に悪意のロジックが潜んでいて、それが作動する |
| スクリプトモジュール自体には悪意のコードは含まれていないが、いわゆるDOMベースのスクリプト注入（注釈1）を防ぎきれない等の脆弱性が潜在している | |
| (3) ウィジェット型実装 | (2)とほぼ同様 |
注釈1
サービス呼出し型実装
脅威
この呼出し型実装をめぐる脅威として、悪意ある他者が運営するサーバから得られた応答の中に攻撃データが含まれる、というものが考えられる。例えば、次のような文字列が返されて来て、この値をそのままDOM要素のinnerHTML属性へ書き込んだ場合、悪意のスクリプトが実行されるおそれがある。
<img src=x onerror=悪意のスクリプト>
ただし、この呼出し型実装においては、XMLHttpRequestの応答の妥当性を厳密に検査することによって、セキュリティ侵害の多くを未然に防ぐことが期待できる。
スクリプト取り込み型実装
第1の脅威
スクリプト取り込み型実装をめぐる第1の脅威として、ロードしたスクリプトモジュールの中に悪意あるロジックが潜んでいて、それが作動する、というものが考えられる。
- ロードしたスクリプトモジュールが想定外のネットワークアクセスを行い、DOM上の情報が漏洩する。
- ロードしたスクリプトモジュールが想定外のユーザインタフェースを表示し、詐欺をはたらく。
- ロードしたスクリプトモジュールが、さらなる侵害のために、別のスクリプトモジュールや新たなウィジェット（web widget、ユーザインタフェース部品のこと）をどこかのサーバからロードする。
上記からわかるように、他者の用意したスクリプトモジュールをそのままロードすることにはリスクを伴う。ロードしたスクリプトモジュールにはDOMのあらゆる部分に干渉する機会を与えるからである。
このような場合の対策として、例えば、Dojoプロジェクトのdojox.secure.sandboxモジュールによるサンドボックス機能が存在する。
第2の脅威
スクリプト取り込み型実装をめぐる第2の脅威として、スクリプトモジュール自体には悪意のコードは含まれていないが、DOMベースのスクリプト注入攻撃を防ぎきれない等の脆弱性が潜在していることが考えられる。
JavaScriptコードを十分検証して脆弱性を排除できれば理想的であるが、第三者の手によるソフトウェアの品質を保証することは容易でない。
その代わり、サードパーティのスクリプトモジュールとデータをやり取りする際に次の対策を施す。
- サードパーティのモジュールへ渡す値は、それがスクリプト注入攻撃パターンの文字列を含まないことを確認してから渡す。
- サードパーティのモジュールから受け取った値は、それがスクリプト注入攻撃パターンの文字列を含まないことを確認してから使用する。
これは、あたかもサードパーティのスクリプトモジュールを「攻撃データの入口」かつ「攻撃の発火点」と見なして扱うということでもある。
ウィジェット型実装
第1と第2の脅威
ウィジェット型実装は、ブラウザに最初にロードされるコンポーネントがスクリプトファイルではなくHTMLファイルであることの違いを除き、前述の「スクリプト取り込み型実装」と事情は似ている。したがって、脅威の捉え方も「スクリプト取り込み型実装」とほぼ同様である。
しかし、大きく異なる点がひとつある。画面上のウィジェットの配置に<iframe>タグを用いることによって、<iframe>の内と外でコンテンツの源泉（出身サーバ）が異なる場合は、互いに相手のDOMにアクセスすることができないため、ウィジェット内のスクリプトから干渉されるのを避けることができる。
ただし、異なる源泉の間でも<iframe>の内外でデータを交換する方法は存在している。例えば、window.postMessage()を使うと、<iframe>の内と外で双方向の交信が可能である。ここでも、他者の手によるコンテンツから受信したメッセージについては、何らかの攻撃データが仕込まれていないか検査した上で使用し、送り出すメッセージにはスクリプトとして機能する文字列が含まれていないことを確実にした上で送信することが重要である。
なお、「ウィジェット」と称されるマッシュアップ向けAPIが実際にはJavaScriptファイルをロードする仕組みをとっていて、実体は「スクリプト取り込み型実装」であるものも少なくない。