WASCのWeb Security MLで、「Security Restriction」（以降SRと略します）という新しいセキュリティ機構の案が提示され、議論されています。
The websecurity August 2007 Archive by thread
この方（Agarwal氏）のメールはいつも見づらいのですが、その辺は置いておいて、以下に内容を抜粋します。
I am looking to get views from people on the list about a proposed security restriction in the browsers. The browser should check with the webserver which domains it can interact with (load files from or submit post data to, etc) for that website. How the check is implemented is upto the browser.
For example: If a page from mybank.com is trying to submit data to attacker.com then before submitting the data, the browser should check with the mybank.com if it is allowed to do so.
The websecurity August 2007 Archive by thread
このような機構の目的は、XSS脆弱性が存在した場合に生じる被害を少なくすることです。
XSS攻撃での典型的な脅威は、セッション管理に使用されるCookieの窃取や、偽のログインフォームを使ったログインID/パスワードの窃取などです。通常、攻撃者は盗んだ情報を自身の支配下のサーバに転送しようとするでしょう。
上記の機構は、主にこのような「情報の出口」を塞ぐ役割を担うものだと考えられます。
出口を防ぐアプローチの限界
しかし、このような「出口を塞ぐ」アプローチには限界があります。
まず、SRは、情報を外部に盗み出す以外のタイプの攻撃に対しては効果はありません。このような攻撃には、単純にページ表示文言の改竄や、CSRF対策を破るようなものが考えられます（JavaScript Wormなども含まれます）。
また「出口」には、様々なタイプのものがあります。まず思い付くのは、img/frame/script/styleタグなどのsrc属性、formタグのaction属性を利用するものです。
それ以外にも、リンクや、ウィンドウのオープンや、リダイレクトなどを通じて、外部サイトに情報を送ることができます。徹底的に出口を塞ぐのならば、これらも規制の対象にしなければなりません。src属性やaction属性はともかく、リンク先のドメインをも制限するとしたらSRは非常に使いづらいものとなると思われます。
上記のような割とまともな方法以外にも、単純にクリップボードを使ったり、CSS History Hackの手法を応用したりすることで、外部サイトにデータを受け渡すこともできます。
クリップボードの件はIEの脆弱性、CSS History Hackは現行のWebの仕組みの欠陥と言った方が正確だと思いますが、外部サイトにデータを渡す手段を完全に塞ぐのは困難だということは確かです。
元から絶ったほうがよい
上記したように、ブラウザは外部サイトとの「interact」に使用可能な手段を多く提供しています。XSSされた状況というのは、いわば「死に体」であって、攻撃者はそれらの手段を殆ど自由に使用することができます。
Agarwal氏のMLへの投稿に書かれたものがSRの全てであるならば、これは「死に体」の状況で何とかしようとするものであり、完全なものにするのは困難だろうと思います。
Content Restriction
SRと少し似ている「Content Restriction」（以下CRと略します）という提案があります。
これも、ブラウザの機能拡張を前提とするAnti-XSS機構ですが、SRとは異なり、XSSの予防（つまり死に体にならないこと）に重点を置いたものです。
昨年末の日記で少し触れましたが、CRでは「このページではJavaScript禁止」「headタグ内でのみJavaScript許可」「特定のサイト上のJSファイル（<script src=...で呼び出す）でのみJavaScript許可」のようなオプションを、レスポンス内に指定する仕組みなどが提案されています。
しかし、これとても完全な対策ではありません。仮にheadタグ内のみでスクリプトの使用を許可しても、headタグ内にXSS脆弱性があるならば意味がありません。そうでなくても、JavaScriptを使わずに、actionが攻撃者のサイトになっている偽のログインフォームをXSS（というよりHTMLインジェクション）の脆弱性を突いて仕込むような攻撃には、CRは無防備です。
また、headタグ内やJSファイルでのみJavaScriptが使用可能な場合、ボタンのonclickなどでJavaScriptを起動したい場合などに、「イベントハンドラをHTMLから分離する 基本サンプル [Javascript] All About」のようなプログラムの書き方が要求されるため、使いづらいのではないかと思います。
CRがFirefox3に搭載されるかも
CRについては、Web Security MLのSRに関する議論でも何度か取り上げられています。
その中で、CRの発案者であるGerv氏の投稿には、以下のようなことが書かれていました。
Although parts of it are Priority 1 items in the Firefox 3 Product Requirements Document.
The websecurity August 2007 Archive by thread
上の引用文内の「it」はCRを指しています（Firefox3のwikiでもそれが確認できます）。
実際にFirefox3に実装されるかはよく判りませんが、今後どうなるか興味があります。
