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

[Maciej Stachowiak]

On Sep 25, 2008, at 1:17 PM, Collin Jackson wrote:

> 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)

Another variant of this or Michal's #1 is an HTML-level concept (such  
as a meta keyword). Or if it remains an HTTP header, it should be  
allowed for <meta http-equiv> (which in HTML5 allows only a small  
subset of http headers).

In general, your 6 and 7 sound much more practical than Michal's #3  
and less likely to have unexpected bad effects on existing sites.

Regards,
Maciej


>
>
> [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>