第8章 6.クライアントサイドマッシュアップ：対策に利用できる技術

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

Webクライアントにおけるセキュリティ対策対象レイヤ

クライアントサイドマッシュアップにおけるセキュリティ確保については、アプリケーションコードレベル、ライブラリレベル、ブラウザ（JavaScriptエンジン）レベルの各階層に分けて説明する。

特に、ブラウザレベルの対策が充実すると、開発者の負担は軽くなることが期待される。

サーバからブラウザ宛のレスポンスヘッダ内に、セキュリティ対策のふるまいを指定する仕様が複数、存在している。

(1) セキュリティ対策機能をオンにするためのヘッダ

サーバからロードされるコンテンツに添えられるレスポンスヘッダに、何らかのセキュリティポリシーの執行をブラウザへ要請する用途のものが増えてきた。例えば、次のレスポンスヘッダである。

• X-XSS-Protection
  
  • XSSフィルタの有効/無効
• X-Frame-Options
  • コンテンツのフレーム内における表示を許す/許さない
• X-Content-Type-Options
  • 内容からのコンテントタイプの推測をする/しない

主要なブラウザと、これらのヘッダのサポート状況は下表の通りである。

1. 出典：
   Browser Scope Has Merged With Aussie Hosting

Google Chrome Frame の影響

Google Chrome Frame（以下 GCF）は、Internet Explorer の上で HTML5 の機能をフルに利用できるようにすることを意図したプラグインである。GCF は、X-UA-Compatiblle: chrome=1等のレスポンスヘッダによって活性化され、Webページのレンダリングそのものを引き受ける。

Google Chrome Frame は、独立したブラウザGoogle Chrome と近い動きをするが、違いもある。上記の表のセキュリティ対策レスポンスヘッダも有効であるが、動作が必ずしも確実でない場合がある。

(2)「CSP（Contents Security Policy）」によるスクリプト動作の制限

Content Security Policy は、スクリプトのロードと実行等に強い制約を設ける機能であり、Mozilla Firefox に最初に実装された。

アクセスできる源泉のホワイトリストを掲げ、原則としてインラインスクリプトを禁止する。

レスポンスヘッダ内に Content Security Policy を指定するラベルには、現在、下記のように複数のものが存在しており統一されていない。（2013年12月時点）

現在、W3Cの規格の対策機能は、下記の形のレスポンスヘッダを Internet Explorer 以外のブラウザが受信すると活性化される。

Content-Security-Policy: 仕様

Webコンテンツ内のスクリプトの配置の自由度は減るが、どのスクリプトが実行されどれが禁止されるかを客観的に把握しつつ対策を行えるのが特長である。

最も単純な例

この仕様には複雑な指定が可能であるが、最も単純な指定の例は下記のようになる。

Content-Security-Policy: default-src 'self'

これによって、ブラウザにおけるスクリプトの実行が次のように制約されるようになる。

• HTML の途中に次のような形で記述する、いわゆる「インライン」のスクリプトは実行が禁止される。

<script>スクリプトソースコード</script>　　　　← これは禁止

• 動作させたいスクリプトは原則として、次の形で独立した別のコンテンツとして呼び込まなくてはならない。

<script src="スクリプトURI"></script>　　　　← この形式のみ許される

この「スクリプトURI」として許されるのは、この Webページの源泉と同じサーバに限られる。

• 文字列をスクリプトのソースコードとして解釈実行する eval()等の関数の実行が禁止される。

Content-Security-Policy のパラメータ

Content-Security-Policyレスポンスヘッダは、多くのパラメータもっていて、よりきめ細かな指定をすることができる。

Content-Security-Policy: default-src ホスト...

　　[; img-src ホスト...][; media-src ホスト...]
　　[; srcipt-src ホスト...][; object-src ホスト...]
　　[; frame-src ホスト...][; font-src ホスト...]
　　[; xhr-src ホスト...][; frame-ancesors ホスト...]
　　[; style-src ホスト...]
　　[; report-uri URI][; policy-uri URI]

• ホスト名を具体的に羅列することによって、Webページの源泉以外のサーバからのスクリプトのロードを許可／限定できる。：

script-src ホスト...

• スクリプトのロード元を許可するのと同様の要領で、画像等各種リソースのロード元のホストを明示できる。：

img-src ホスト...; media-src ホスト...; style-src ホスト...; ...

• Webページの源泉のホスト（自分自身のサーバ）からの追加リソースのロードを禁止することもできる。：

default-src 'none' [別のホスト...]

• せっかくのインラインスクリプトや eval（）の禁止機能であるが、その禁止を解除することもできる。：

script-src 'self' 'unsafe-inline' 'unsafe-eval'

• 現時点では、まだ報告される項目が少ないようであるが、指定されたホストにエラー報告を行うような機能も備わる模様である。：

report-uri URI

(3) 他ドメインJavaScript のサンドボックスを用いたロードと実行

ブラウザ自体あるいは Add-onツールを加えてサンドボックスが構築されて、それが一定のポリシーを適用する機能を果たすものがある。ブラウザ自体が実装しているのは Mozilla であり、Add-onツールとして提供されているのは、Dojox.secure である。いずれも、eval()関数を止めたり、innerHTMLを抑止したりする機能を備えている。

dojox.secure といったライブラリを使用すると、必ずしも信頼できるとは限らない他者のドメインからJavaScript をロードして呼び出す場面でも、そのスクリプトをいわゆる「サンドボックス」の中で安全に実行させることができる。

<div id="attatch_point">
　　サンドボックスにロードされるスクリプトからアクセスできるDOMの
　　要素は、このdivノードと、ここに作られる子孫のみに制限される
</div>

...

<script>
　　// sandbox部品の確保
　　dojo.require("dojox.secure.sandbox");

　　// サンドボックスオブジェクトの生成と、そこへのスクリプトのロード
　　var sb = dojox.secure.sandbox(dojo.byId("attatch_point"));
　　var foreignCode = sb.loadJS("http://others/foreign_code.js");

　　// ロードしたコードに対するメソッド呼出しや、イベントハンドラの接続
　　foreignCode.someMethod(...);
　　dojo.connect(foreignCode, "someEvent", function(arg){...});
　　...
</script>
...

(4) OAuth 2.0 を用いたクライアントサイドマッシュアップ

OAuth 2.0 を用いてクライアントの権限の委譲を伝えるしくみについては、別途作成している『アイデンティティ管理技術解説』中の「インターネット上の代理アクセス」の内容を踏まえて述べる予定である。

他源泉リクエスト状況におけるリクエスト強要対策

他源泉におけるリクエスト強要対策は、セッション対策 、XHR 2 の慎重な利用等から成る。

(1) セッション対策（トークン対策）

• 「非同期の他源泉リクエスト」においては、できるだけセッションを用いない。

• セッション維持が必要な場合であっても Cookie は用いない (Basic認証やDigest認証も同様)。セッションID を POSTデータで搬送する対策例を下図に示す。

• 

• データ供給サイトのサーバで他者が推測困難なトークンを発行し、ブラウザから送られてきたトークンの照合を行う。トークンを照合する対策例を下図に示す。

• 

• OAuth のアクセストークンを利用する。本稿執筆現在、OAuth 2.0が策定途中であり、一部の Webサイトではそれを先取りした実装の使用が始まっている。

(2) XHR 2の利用

他源泉リクエスト発行手段には XHR 2 を選ぶ。（IE 8専用には XDR を選ぶ。）

その際にサーバでは Origin: を厳密に検査する。

また、Access-Control-Allow-Origin: の発行を必要最小限にする。

(3) 他源泉リクエストを必要最小限に

そもそも、他源泉リクエストの使用を必要最小限に留める。

クライアントサイドマッシュアップからサーバサイドマッシュアップへ

クライアントサイドマッシュアップをサーバサイドマッシュアップに移行すると、「3.クライアントサイドマッシュアップ：悪意のAPIサイトからの脅威」および「5.クライアントサイドマッシュアップ：リクエスト強要攻撃による善意のAPIへの侵害」において説明した各種の脅威を低減することができる。移行のし易さや課題を「3.クライアントサイドマッシュアップ：悪意のAPIサイトからの脅威」で取り上げた 3種類のAPI呼出しの実装形態別に示す。

• 3.クライアントサイドマッシュアップ：悪意のAPIサイトからの脅威
• 5.クライアントサイドマッシュアップ：リクエスト強要攻撃による善意のAPIへの侵害