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

[Collin Jackson]

On Thu, Sep 25, 2008 at 10:24 AM, Michal Zalewski <lcamtuf at dione.cc> wrote:
> Other quick fixes are easy to come up with, but in general prove problematic
> in many usage scenarios. Based on our internal conversations, we have a
> number of proposals for approaches to how to address the issue, along with
> their pros and cons outlined. All these could be tweaked, combined, etc.;
> none of them seems quite ideal.

Here are two ideas to add to the mix:

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. In a CSRF or "UI redress"
attack scenario, it will appear as though the user is not logged in,
and thus the HTTP request will be unable to affect the user's account.

This flag could potentially use the cookie concept of same origin
rather than the HTML5 concept of same origin: ignore port, ignore
scheme unless "secure" flag is set, "domain" attribute can be used to
relax domain comparison.

Pros:

 - Only need to change one line of code where the login cookie is set,
entire site is protected

Cons:

 - "Opt-in" (sites remain vulnerable unless action is taken)
 - Would need to test this to make sure it doesn't break legacy
browser cookie handling

(Adam and I got this idea from someone else, but we don't remember who it was.)

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. This header could be a list of all the origins that
are ancestors of the frame that triggered the request. If the site
decides it does not like the ancestor frame origin it could reject the
request. This could be added as a property of MessageEvent as well to
detect client-side-only UI redress attacks.

Pros:

 - Doesn't break existing sites
 - Easy to check using firewall rules

Cons:

 - "Opt-in" (sites remain vulnerable unless action is taken)
 - Minor increase in HTTP request size (but only for iframe-heavy sites)

[1] <http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#messageevent>
[2] <http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#postmessage0>
[3] <http://www.w3.org/TR/access-control/#origin0>
[4] <https://bugzilla.mozilla.org/show_bug.cgi?id=446344>
[5] <https://bugs.webkit.org/show_bug.cgi?id=20792>