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

[Michal Zalewski]

Hi folks,

I am posting here on the advice of Ian Hickson; I'm new to the list, so 
please forgive me if any of this brings up long-dismissed concepts; 
hopefully not.

For a couple of months now, along with a number of my colleagues at 
Google, we were investigating a security problem that we feel is very 
difficult or impossible to avoid on application side, and might be best 
addressed on HTML or HTTP level in contemporary browsers. These problems 
had recently gained some mainstream attention, and so we hoped to discuss 
potential solutions, and perhaps gain some traction for long-term fixes.

Problem definition: a malicious page in domain A may create an IFRAME 
pointing to an application in domain B, to which the user is currently 
authenticated with cookies. The top-level page may then cover portions of 
the IFRAME with other visual elements to seamlessly hide everything but a 
single UI button in domain B, such as "delete all items", "click to add 
Bob as a friend", etc. It may then provide own, misleading UI that implies 
that the button serves a different purpose and is a part of site A, 
inviting the user to click it. Although the examples above are naive, this 
is clearly a problem for a good number of modern, complex web 
applications.

Practical, real-world examples of such "UI redress" attacks were 
demonstrated in the past, and recently resurfaced on an OWASP conference 
(under the name of "clickjacking"); some references include:

  * http://www.thespanner.co.uk/2008/02/11/csrf-chat/
  * https://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference
  * http://lists.immunitysec.com/pipermail/dailydave/2008-September/005356.html

We feel that current web browser designs provide no adequate tools for web 
site owners to protect their applications against such attacks. The two 
workarounds often employed right now are:

1) Using Javascript hacks to detect that window.top != window to inhibit
    rendering, or override window.top.location. These mechanisms work only
    if Javascript is enabled, however, and are not guaranteed to be
    reliable or future-safe. If the check is carried on every UI click,
    performance penalties apply, too. Not to mention, the extra complexity
    is just counterintuitive and weird.

2) Requiring non-trivial reauthentication (captcha, password reentry) on
    all UI actions with any potential for abuse. Although this is
    acceptable for certain critical operations, doing so every time a
    person adds Bob as a friend on a social networking site, or deletes a
    single mail in a webmail system, is very impractical.

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.

Proposed fixes:

1) Create a HTTP-level (or HTTP-EQUIV) mechanism along the lines of
    "X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes" that permits a web
    page to inhibit frame rendering in potentially dangerous situations.

    Pros:

    - Super-simple

    Cons:

    - "Opt-in", i.e. currently vulnerable sites remain vulnerable unless
      action is taken

    - Can't be used for cases where IFRAME content mixing has a legitimate
      purpose (for example, cross-domain gadgets, certain types of mashups)

    - Adds yet another security measure (along with cross-domain XHR, MSIE8
      XSS filters, MSIE P3P cookie behavior, Mozilla security policies)
      that needs to be employed correctly everywhere to work - which is
      very unlikely to consistently happen in practice

    - Along with the aforementioned security features, threatens to
      result in HTTP header or HTML HTTP-EQUIV size bloat that some sites
      may care about.

2) Add a document-level mechanism to make "if nested <show this> else
    <show that>" conditionals possible without Javascript. One proposal is
    to do this on the level of CSS (by using either the media-dependency
    features of CSS or special classes); another is to introduce new HTML
    tags. This would make it possible for pages to defend themselves even
    in environments where Javascript is disabled or limited.

    Pros:

    - Lightweight

    - Far more fine-grained than proposal #1 (though still not perfect)

    Cons:

    - "Opt-in" (sites remain vulnerable unless action is taken)

    - Might seem like an odd abuse of CSS / HTML

3) Add an on-by-default mechanism that prevents UI actions to be taken
    when a document tries to obstruct portions of a non-same-origin frame.
    By carefully designing the mechanism, we can prevent legitimate uses
    (such as dynamic menus that overlap with advertisements, gadgets, etc)
    from being affected, yet achieve a high reliability in stopping
    attacks.

    [ I like this one the most myself, but we were far from reaching any
      consensus. ]

    Algorithm description:

    A) Permit frames to be nested arbitrarily by default.

    B) If anything is to be drawn partly or fully on top of a region
       occupied by a nested IFRAME (in a callback from the renderer), look
       up the parent of the obstructing visual element drawn (that is, the
       party in charge of element's positioning). Always allow the element
       to be drawn, but if the parent is not same-origin with the target of
       an obstructed IFRAME, set a flag to disable UI input to that
       obstructed IFRAME (i.e., have the browser sink all UI events from
       now on). We may also gray out the disabled IFRAME (and maybe allow
       CSS to customize this behavior for specific IFRAMES).

    C) Treat a case where top-left corner of the IFRAME is drawn out of
       a visible area (CSS negative margins, etc) as a special case of
       being obstructed by the owner of a current rendering rectangle
       (another IFRAME or window.top) and carry out the same comparison.

    D) Once the obstruction is removed (say, a menu folded back), initiate
       a security timer (500-1000 ms or so) to eventually re-enable UI
       input to the IFRAME.

    E) Cases where a non-same-origin IFRAME is newly spawned by
       Javascript, or same-origin -> non-same-origin location updates takes
       place, should be treated as special cases of the IFRAME being
       uncloaked, and result in UI event lockout until a security timer
       expires.

    F) Regardless of the aforementioned mechanism, do not permit an
       IFRAME target that is not same-origin with its parent document to
       invoke .focus() or to reposition content using URL anchors. This is
       to make sure that the top-left corner of the page as seen by the
       user always displays the top-left corner of the actual page.

    A potential optimization for D) and E), to minimize any potential
    impact where attacks are unlikely to succeed, is to:

    - Permit a short window of opportunity (0.5 second, perhaps)
      following initial page load, as well as possibly mouse clicks, during
      which cross-domain IFRAMEs may be revealed with no timer penalty,
      based on the assumption that immediate and involuntary UI actions
      are unlikely to follow.

    ...or alternatively:

    - Disable UI events or initiate timeouts only if cursor is within a
      certain radius of the uncloaked non-same-origin frame, based on the
      same assumption.

    Pros:

    - Works by default

    Cons:

    - Moderately complex and kludgy

    - In implementations, would require callbacks from the renderer to
      detect obstruction, as opposed to making decisions without this
      knowledge

    - Further investigation is needed to verify that this doesn't break the
      legitimate and common practice of some sites


4) Enforce a click-to-work mechanism (resembling the Eolas patent
    workaround) for all cross-domain IFRAMEs.

    Pros:

    - Works by default

    - Very simple

    Cons:

    - May be cumbersome for users

    - May not play well with gadgets, advertisements, etc.

5) Rework everything we know about HTML / browser security models to
    make it possible for domains and pages to specify very specific opt-in
    / opt-out policies for all types of linking, referencing, such that
    countering UI redress attacks would be just one of the cases controlled
    by this mechanism.

    Pros:

    - Awesome in theory, security-wise

    Cons:

    - Not really going to happen any time soon

Cheers,
/mz