[whatwg] Dealing with UI redress vulnerabilities inherent to the current web

[Michal Zalewski]

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