セキュリティセンターTOP > セキュアプログラミング講座 > Webアプリケーション編 > マッシュアップ > クライアントサイドマッシュアップ: #2 悪意のAPIサイトからの脅威

第8章 マッシュアップ
クライアントサイドマッシュアップ: #2 悪意のAPIサイトからの脅威

シナリオ1〜3は、悪意のAPIサイトによってクライアントが侵害されるというものである。本節ではこれらのシナリオについて論じる。

以降ではAPI呼出しの形態を複数に分け、それぞれにおける悪意のAPIサイトからの脅威を考察する。

クライアントサイドマッシュアップの複数の実装形態

ブラウザ上にロードされたコンテンツの内部から直接、サードパーティ（サイトの主催者や利用者とは異なる立場の企業・団体等）のWebサーバのリソースを利用するのがクライアントサイドマッシュアップである。サードパーティのリソースを利用する形態には次の3種類がある。

これらの実装形態ごとの脅威を次の表に示す。

表：マッシュアップAPI呼出しの実装形態ごとの脅威
実装形態 脅威
(1) サービス呼出し型実装 必ずしも高い信頼のおけない「他者の運営するサーバ」から得られた応答の中に攻撃データが含まれる
(2) スクリプト取り込み型実装 ロードしたスクリプトモジュールの中に悪意のロジックが潜んでいて、それが作動する
スクリプトモジュール自体には悪意のコードは含まれていないが、DOMベースのスクリプト注入（XSS）攻撃を防ぎきれない等の脆弱性が潜在している
(3) ウィジェット型実装 (2)とほぼ同様

DOMベースのスクリプト注入（XSS）

「DOMベースのスクリプト注入（XSS）」は、これまでも知られていた スクリプト注入（XSS） 攻撃の新たな実行手口である。

従来、スクリプト注入の実行手口は、ブラウザが受け取る Web コンテンツ中に悪意の JavaScript ソースコードが混入するよう、細工した入力データを Web サーバ上のプログラムへ送りこむものだった。

これに対し「DOMベースのスクリプト注入」は、ブラウザ上の善意の JavaScript プログラムに向けて細工したデータを送り込み、それがスクリプトとして実行されるよう（その結果として侵害が起こるよう）はかるものである。

細かな攻撃テクニックは多岐にわたる。例えば、アプリケーションの JavaScript プログラムが HTML タグの innerHTML プロパティに値を設定している箇所を標的にして、<script> タグを表す文字列を攻撃者が（やはり JavaScript プログラムを経由して）送り込むといったやり方がある。これらのテクニックに共通するのは、DOM（Document Object Model、HTMLタグ要素へのアクセスと書換えの手段）の使用場面が多く利用される点である。それゆえ「DOMベースの...」と呼ばれる。



サービス呼出し型実装


サービス呼出し型実装
図8-3： サービス呼出し型実装

脅威

この呼出し型実装をめぐる脅威として、悪意ある他者が運営するサーバから得られた応答の中に攻撃データが含まれる、というものが考えられる。例えば、次のような文字列が返されて来て、この値をそのままDOM要素のinnerHTML属性へ書き込んだ場合、悪意のスクリプトが実行されるおそれがある。

<img src=x onerror=悪意のスクリプト>

ただし、この呼出し型実装においては、XMLHttpRequestの応答の妥当性を厳密に検査することによって、セキュリティ侵害の多くを未然に防ぐことが期待できる。


スクリプト取り込み型実装


スクリプト取り込み型実装
図8-4： スクリプト取り込み型実装

第1の脅威

スクリプト取り込み型実装をめぐる第1の脅威として、ロードしたスクリプトモジュールの中に悪意あるロジックが潜んでいて、それが作動する、というものが考えられる。

上記からわかるように、他者の用意したスクリプトモジュールをそのままロードすることにはリスクを伴う。ロードしたスクリプトモジュールにはDOMのあらゆる部分に干渉する機会を与えるからである。

このような場合の対策として、例えば、Dojoプロジェクトのdojox.secure.sandboxモジュールによるサンドボックス機能が存在する。

第2の脅威

スクリプト取り込み型実装をめぐる第2の脅威として、スクリプトモジュール自体には悪意のコードは含まれていないが、DOMベースのスクリプト注入（XSS）攻撃を防ぎきれない等の脆弱性が潜在していることが考えられる。

JavaScriptコードを十分検証して脆弱性を排除できれば理想的であるが、第三者の手によるソフトウェアの品質を保証することは容易でない。

その代わり、サードパーティのスクリプトモジュールとデータをやり取りする際に次の対策を施す。

これは、あたかもサードパーティのスクリプトモジュールを「攻撃データの入口」かつ「攻撃の発火点」と見なして扱うということでもある。


ウィジェット型実装


ウィジェット型実装
図8-5： ウィジェット型実装

第1と第2の脅威

ウィジェット型実装は、ブラウザに最初にロードされるコンポーネントがスクリプトファイルではなくHTMLファイルであることの違いを除き、前述の「スクリプト取り込み型実装」と事情は似ている。したがって、脅威の捉え方も「スクリプト取り込み型実装」とほぼ同様である。

しかし、大きく異なる点がひとつある。画面上のウィジェットの配置に<iframe>タグを用いることによって、<iframe>の内と外でコンテンツの源泉（出身サーバ）が異なる場合は、互いに相手のDOMにアクセスすることができないため、ウィジェット内のスクリプトから干渉されるのを避けることができる。

ただし、異なる源泉の間でも<iframe>の内外でデータを交換する方法は存在している。例えば、window.postMessage()を使うと、<iframe>の内と外で双方向の交信が可能である。ここでも、他者の手によるコンテンツから受信したメッセージについては、何らかの攻撃データが仕込まれていないか検査した上で使用し、送り出すメッセージにはスクリプトとして機能する文字列が含まれていないことを確実にした上で送信することが重要である。

なお、「ウィジェット」と称されるマッシュアップ向けAPIが実際にはJavaScriptファイルをロードする仕組みをとっていて、実体は「スクリプト取り込み型実装」であるものも少なくない。

 

次の記事へ
ページトップへ