On Thu, 25 Sep 2008, Collin Jackson wrote:
6) New cookie attribute: The "httpOnly" cookie flag allows sites to put restrictions on how a cookie can be accessed. We could allow a new flag to be specified in the Set-Cookie header that is designed to prevent CSRF and "UI redress" attacks. If a cookie is set with a "sameOrigin" flag, we could prevent that cookie from being sent on HTTP requests that are initiated by other origins, or were made by frames with ancestors of other origins.
Good point; the concern with this, as with most of the other schemes except for #3, is that it breaks some legitimate cross-domain uses such as gadgets and mashups (we can either permit anyone to partly or fully display a gadget, or deny everyone; we would ideally want to restrict partial rendering only).
Just as importantly, some sites are moving to different-domain content hosting domains specifically to work around countless bugs, oddities, and design flaws in modern browsers (starting with MSIE text/plain / image/* behavior and utf-7 sniffing, through Content-Disposition bypass issues, to the complete inability to safely serve certain types of non-sanitized resources in sensitive domains). Customizable policy frameworks may help with this in the long run, but for now, it's a necessity. Any solution that puts blanket cross-domain restrictions on IFRAME nesting would need to be completely disabled in such scenarios.
This is why I and several people like #3 best, despite its relative complexity - because it does not require you to fully expose your content to third-party domains.
7) New HTTP request header: Browser vendors seem to be moving away from "same origin restrictions" towards "verifiable origin labels" that let the site decide whether two security origins trust each other. Recent examples of this are MessageEvent's "origin" property [1], postMessage's "targetOrigin" argument [2], and the HTTP "Origin" header [3] [4] [5]. We can adjust proposal (1) to conform to this philosophy: instead of making it an "X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes" HTTP response header, make it an "X-Ancestor-Frame-Origin: http://www.evil.com"; HTTP request header.
Oh yup, I wanted to capture this possibility in #5; it's a noble long-term goal, but with the conflicting proposals from Microsoft, Mozilla developers, and several other parties, and the high complexity of getting these mechanisms right - I am not sure it's a viable solution for the next few years. Maybe in 5-10, it would be a reality.
/mz
