クロスドメインモデルの理解

1. クロスドメインモデルの理解 Peleus Uhley PacSec 2008

2. 概要 • 導入 • クロスドメイン通信の歴史 • HTMLにおけるクロスドメイン • プラグインにおけるクロスドメイン • 比較表 • クロスドメイン実装のベストプラクティス • 結論

3. 同一元ポリシー • ウェブサイトのコンテンツが、他のウェブサイトのコンテンツから読み出しや変更できるのは望ましくない • ブラウザセキュリティの基本構成要素

4. GETとPOST • ドメイン間の情報送信は常に許可されてきた • レスポンスの読み取りは同一元ポリシーによって制限されていた • クロスサイトリクエストフォージェリ

5. 他のトリック • JSON-P • 別ドメインへ情報を渡すために、scriptタグとJSONデータ＋コールバック関数を利用 • Not inline with the intention of the JSON format（※未訳） • Document.domainの書き換え • www.example.org を example.org に短縮するために利用できる • インポート読み込み • scriptタグはリクエストに応じて動的なJavaScriptを返すCGIを指定することができる • プラグインは他のドメインからSWFをインポートすることができる • HTTPの代替物 • ソケット、ローカルコネクション、他のプロトコルなど

6. これらのソリューションによって何ができるのか？これらのソリューションによって何ができるのか？ • 開発者は、クロスサイトリクエストフォージェリの危険がない、クロスドメイン通信の手法を必要としている • 2つのドメインが同じ開発グループによってコントロールされているか、承認されたAPIがあるならば、クロスドメインに危険性はない • www.example.org と data.example.org • できるだけ多くの人に利用してもらうために、明示的にウェブに情報を公開する場合がある • 毎日の株価情報 • 選挙の結果 • 天気予報

7. HTML での規格

8. Microsoft XDR • IE 8 Beta 1にて導入 • マイクロソフトのインタネットゾーンに基づいたセキュリティ • プロトコルが一致していなければならない(file:// <-> file://) • クッキー: クッキーは送らない • HTTPメソッド: GETとPOSTのみを許可 • 改良点: URI毎 • Beta2 では W3 Access-ControlのAccess-Control-Allow-Originヘッダをサポートするよう改訂された

9. XDR サンプルコード if (window.XDomainRequest) { xdr = new XDomainRequest(); if (xdr) { //Assign handlers to xdr {not shown} xdr.open(“POST", “http://www.example.org/xdr.cgi”); xdr.send(“HTTP_VAR=hello%20World”); } function readdata() { var dRes = document.getElementById('dResponse'); dRes.innerText = xdr.responseText; alert("Content-type: " + xdr.contentType); alert("Length: " + xdr.responseText.length); }

10. W3C Access Control • クロスドメインXMLHTTP リクエスト（XHR）を許可 • 最近MicorosoftとMozillaが承認 • まだ開発中段階 • クロスドメインの認可情報をヘッダで送信 • レスポンスはフルURI単位

11. Pre-Flight リクエスト • Pre-flightリクエストは、以下のようなカスタマイズされたリクエストが行われる場合に実行される: • GET, POST, HEAD 以外のメソッドを利用 • カスタムヘッダを利用 • Content-typeヘッダがapplication/x-www-form-urlencoded, multipart/form-data, text/plain以外 • Pre-flightリクエストでは、OPTIONSメソッドが使われる

12. Pre-Flight リクエストヘッダ • Origin リクエストヘッダ • リクエスト元を指定 • Access-Control-Request-Method リクエストヘッダ • GETやPOST以外の利用したいHTTPメソッドを指定 • Access-Control-Request-Headers リクエストヘッダ • XHRが含む予定の追加ヘッダを指定

13. W3C Access Control レスポンスヘッダ • Access-Control-Allow-Origin レスポンスヘッダ • クロスドメイン通信が許可されているリクエスト送信元 • “*”はどこからでもアクセスを許可 • Access-Control-Max-Age レスポンスヘッダ • pre-flightリクエストの結果をキャッシュする期間 • Access-Control-Allow-Credentials レスポンスヘッダ • クッキー、HTTP 認証ヘッダや他の認証情報が必要かどうかを示す • Access-Control-Allow-Methods レスポンスヘッダ • リクエストを許可するHTTPメソッド一覧 • Access-Control-Allow-Headers レスポンスヘッダ • リクエストに含むことを許可するヘッダ一覧

14. XHR Requestの例 new client = new XMLHttpRequest(); client.open(“CUSTOM", "http://www.example.com/hello") client.onreadystatechange = function() { /* do something */ } client.send()

15. Pre-Flight リクエスト(hello-word -> www) Access-Control-Allow-Origin: http://hello-world.example.org Access-Control-Max-Age: 3628800 Access-Control-Allow-Methods: CUSTOM リクエスト OPTIONS /hello HTTP /1.1 Origin: http://hello-world.example.org Access-Control-Request-Method: CUSTOM レスポンス

16. 実際のリクエスト (hello-world -> www) リクエスト CUSTOM /hello HTTP /1.1 HOST: www.example.org ORIGIN: hello-world.example.org …. レスポンス Access-Control-Allow-Origin: http://hello-world.example.org Hello World!

17. 他の利点 • ORIGINヘッダの導入 • 暫定的な提案では、クロスサイトリクエストフォージェリからの保護のため、XMLHTTPRequest以外でOriginヘッダを利用 • プライバシーの問題もなく、REFERERよりも一貫している • 現在策定中

18. postMessage / クロスドキュメントメッセージング • HTML5Spec内で定義 • Used to send strings of data between frames as GET VARs（※未訳） • Firefox3, IE8, WebKit ナイトリー, Opera 9.5 で対応 • メッセージに”To”アドレスを含めることによってセキュリティコントロール • “To”はワイルドカードの場合もある • 改良点: ドメイン単位

19. data.example.comでのサンプルコード <iframe src="http://www.example.org/message/" id="iframe"></iframe><form id="form"><input type="text" id="msg" value="Message to send"/><input type="submit"/></form><script>window.onload = function(){        var win = document.getElementById("iframe").contentWindow;        document.getElementById("form").onsubmit = function(e){                win.postMessage(                        document.getElementById("msg").value,                        "http://www.example.org"                );                e.preventDefault();        };};</script>

20. 受信 <b>This iframe is located on www.example.org</b><div id="test">Send me a message!</div><script>window.addEventListener("message", function(e){        if ( e.origin !== "http://data.example.com" )                return; document.getElementById("test").textContent = e.origin + " said: " + e.data;}, false);</script>

21. Post processing • IE 8 Beta 2 ではリターンされた文字列を後処理するeval()以外のメソッドが導入される • toStaticHTML -- HTMLからJavaScriptを取り除く • JSON.stringify -- スクリプトオブジェクトをJSONストリングに変換 • JSON.parse -- JSONストリングをJavaScriptオブジェクトに変換

22. Plugin での規格

23. Adobe クロスドメインの歴史 • 2005年にAdobeによって開発 • 最初の公式なクロスドメインモデル • 現在AdobeFlashPlayerとAdobeReaderで使われている • JavaFX,Reader, SilverLightでのさまざまなサポート • メタポリシーとヘッダのための最近のいくつかのアップデート

24. Adobe クロスドメイン • 2005年にAdobeによって開発 • HTTPレスポンスボディの読み込み許可 • ヘッダデータへのアクセスは許可しない • GETリクエストとファイルアップロードを制御 • 認証情報を送信 • HTTPSからHTTPSへの通信は許可 • HTTPからHTTPSへの通信はデフォルトで許可しない • ソケット用の異なるポリシーメカニズムが存在 • ディレクトリ毎のパーミッション

25. 3タイプのコントロール • データを共有したいドメイン • ウェブサイトから受け取りたいカスタムヘッダ • サーバ上に他のクロスドメインポリシーファイルが存在するかどうか

26. クロスドメインポリシーファイルの例 <cross-domain-policy> <site-control permitted-cross-domain-policies="master-only"/> <allow-access-from domain=“example.com“ secure=“true”/> <allow-access-from domain=“*.example.com“ secure=“true”/> <allow-http-request-headers-from domain="www.example.com" headers="SOAPAction" secure=“true"/> </cross-domain-policy>

27. JavaFX • Adobeのcross-domain.xmlファイルのシンプルバージョンをサポート • 基本的には”*”のみサポート • JavaWeb StartとJavaPlug-In技術のために、Java SE 6 update 10で導入 • JavaSE6 update 10は現在リリース候補 • クッキー: 利用

28. Microsoft SilverLight • Adobeの cross-domain ファイルフォーマットのシンプルバージョンをサポート（headersとallow-domain） • 独自のファイルフォーマットをサポート（clientaccesspolicy.xml） • クッキー: 利用 • 改良点: ドメイン単位 & ディレクトリ単位 • HTTPSからHTTPSのクロスドメイン通信は禁止 • HTTPからHTTPSへも禁止 • ソケットパーミッションも同様に定義

29. ClientAccessPolicy ファイルのサンプル <?xml version="1.0" encoding="utf-8"?> <access-policy> <cross-domain-access> <policy> <allow-from> <domain uri=“http://www.adobe.com:80"/> </allow-from> <grant-to> <resource path="/" include-subpaths="true"/> </grant-to> </policy> </cross-domain-access> </access-policy>

30. 他のクロスドメインコントロール • Flash Player AllowScriptAccess OBJECT タグパラメータ • SWFからHTMLDOMへの通信を許可 • クロスドメイン通信を許可しない”sameDomain”がデフォルト • HTMLからSWFへの通信のためには、SWF内の関数が明示的に登録される必要がある • SilverLight • EnabaleHtmlAccessパラメータはSilverLightからHTMLへのクロスドメイン通信を許可 • ExternalCallersFromCrossDomainはHTMLからSilverLightへのクロスドメイン通信を許可

31. 比較

32. ブレークダウン（※もっといい訳を考える）

33. 脅威

34. ヘッダへのアクセス • すべてのモデルはHTTPヘッダへのアクセスを制限しようとしている • これはサーバの以下のような危険な振舞いを防ぐことができる可能性がある: • TRACEメソッドの許可 • レスポンスボディ中のセッションIDをURLの一部として返す

35. クロスサイトスクリプティング • クロスサイトスクリプティングフィルタは新しいJavaScriptでは準備されないかもしれない • JSONのように、開発者はクロスドキュメントメッセージングのデータがどのように扱われるのか、注意する必要があるだろう • 伝統的なクロスサイトスクリプティング攻撃は依然として存在し続けるだろう

36. クロスサイトリクエストフォージェリ • クロスサイトリクエストフォージェリ攻撃はレスポンスデータにアクセスできるかもしれない • 過度に寛容なクロスドメイン実装はこのような攻撃を許してしまう可能性がある • ORIGINヘッダがこのような攻撃を減らす役に立つかもしれない

37. センシティブな情報のリーク • 攻撃者はセンシティブな情報を含むレスポンスボディにアクセスできる • これは最少特権の原理に従わない場合に起こりえる: • ドメインの大本のクロスドメインポリシーでワイルドカードが指定されている • クロスドメインポリシーが特定のサブドメインやファイルに制限されていない • あるモデルでは、サーバが権限を決めるために必要なすべての情報を持っていることを確かめるために、クッキーを送信する（※自信なし） • またあるモデルでは、サーバによる間違いというリスクを避けるために、クッキーを送らない（※自信なし）

38. ベストプラクティス

39. “*” は本質的にevilか？ 適切に適用されない場合、危険となり得る センシティブではないウェブサイト上の、本当にパブリックな情報であればOK 天気予報 選挙結果 株式市場情報 ローカルファイルシステムのコンテンツには必要かもしれない 露出を最小限にするため、ウェブサイトのサブディレクトリに対して適用するべき

40. ドメインのスコープを理解する • コントロールはプロトコルに基づいて制限される？ • コントロールはポートに基づいて制限される？ • コントロールはフルURIに基づいて制限される？ • リモートドメインはユーザによってアップロードされたコンテンツを許可している？

41. “信頼されたコンテンツ”を慎重に定義する • 開発者は、クロスドメインデータを処理するコードを、自分で作成しているので、信頼する傾向にある • しかし、コードは信頼できるとしても、信頼できないデータをパースしている • 開発者はクロスドメインコードを信頼できるドメインにホストするか、コードを別のドメインに移動することによるsame-origin protectionを活用することを考慮すべき

42. クロスドメインリクエストされる側 • ユーザは、あなたが彼らの情報を外部に公開することはないと信頼している、ということを肝に銘じる • ワイルドカードは避ける • 可能であればパスやURIの制限を活用する • 必要なヘッダ以外は許可しない • 必要であればW3CAccessControlによる認証リクエストを行う • センシティブなページではXDMを許可しない • XDMリクエストではtoStaticHTMLやJSONparsingといった安全なデータハンドリングを活用する

43. クロスドメインリクエストする側 • ユーザはあなたが彼らの情報を外部に送ることはないと信頼している • リモートサイトは彼らが持つ情報を、あなたを信頼して預けている • 誰かがネットワーク上でリクエスト元ドメインをスプーフィングするかもしれない • センシティブなデータを含むページに対するXDMを許可しない • データバリデーションを行う

44. クロスドメインを許可しないことを考慮する HTTP/HTTPSが混在したクロスドメイン通信 プロキシによってリレーするのがより適切 センシティブな情報をホストするサイトには、クロスドメインは適さないかもしれない インターナルなウェブサーバでは、ワイルドカードパーミッションが必要

45. 結論

46. Good or Evil? Evil? 開発者はセキュリティに関する決定でミスをするかも 情報共有に関する決定にユーザは関わらない より大きな機能は新しいリスクを生み出す Good? 形式化されたモデルは危険なソリューションに対してより安全な代替案を提供する コントロール方法が形式化されていると、クロスドメインによる情報漏えいの発見や監視が容易になる 古くて危険なソリューションは、時間をかけて強化されていく、または捨てられる

47. 結論 Appropriate for sharing between sites owned by common entities（※未訳） 開発者は、彼らが利用しているものをコントロールすることについて教育される必要がある 設計されたクロスドメイン通信は、アドホックなソリューションよりベターだ さまざまなソリューションは開発者に選択権を与える

48. クロスドメイン通信関連記事 • Cross-domain 101 • http://www.adobe.com/devnet/flashplayer/articles/cross_domain_policy.html • Updates for AJAX in IE8 Beta 2 • http://blogs.msdn.com/ie/archive/2008/10/06/updates-for-ajax-in-ie8-beta-2.aspx • PostMessage API Changes • http://ejohn.org/blog/postmessage-api-changes/

49. テクニカルリファレンス • Adobe Cross-domain • Overview: http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html • Schema: http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html • Access Control Spec • http://dev.w3.org/2006/waf/access-control/ • SilverLight Information • http://msdn.microsoft.com/en-us/library/cc197955(VS.95).aspx • Java • https://jdk6.dev.java.net/plugin2/#CROSSDOMAINXML • Cross-document messaging/PostMessage • Mozilla: https://developer.mozilla.org/En/DOM:window.postMessage • Microsoft: http://msdn.microsoft.com/en-us/library/cc197057(VS.85).aspx

50. Questions?