[whatwg] Dealing with UI redress vulnerabilities inherent to the current web
lcamtuf at dione.cc
Thu Sep 25 13:46:49 PDT 2008
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 , postMessage's
> "targetOrigin" argument , and the HTTP "Origin" header   .
> 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.
More information about the whatwg