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

[Maciej Stachowiak]

On Sep 25, 2008, at 10:24 AM, Michal Zalewski wrote:

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

Isn't this likely to come up any time you have a scrollable iframe, or  
one with overflow: hidden? And why top left but not bottom right?

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

I would add:

- Seems complicated to implement correctly.
- Seems very difficult to validate correctness of the security policy.
- Likely to break user experience of some existing sites.

I do not think this one is viable.

Regards,
Maciej