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

Thu Sep 25 10:24:04 PDT 2008

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