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

[Maciej Stachowiak]

On Sep 25, 2008, at 3:23 PM, Michal Zalewski wrote:

> On Thu, 25 Sep 2008, Maciej Stachowiak wrote:
>
>>> 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?
>
> I meant, corner of the container, rather than actual document  
> rendered within.

Then can't you work around the restriction by scrolling the contents  
inside the iframe and sizing it carefully? (One way to scroll an  
iframe to a desired position is to load a URL containing an anchor link

> If deals strictly with the frame beginning outside the current  
> viewport to hide some of its contents, but leave small portions of  
> the UI exposed to misdirected clicks. Doing the same check for  
> bottom right is very much possible, although does not seem to thwart  
> any particularly plausible attacks.
>
>> - Seems complicated to implement correctly.
>
> It is relatively complex, as acknowledged. The whole reason for this  
> complexity is that we hoped to devise a solution that:
>
>  a) Works by default, without the need to implement specific server- 
> side
>     mechanisms (all things aside, placing the burden on server side is
>     counterintuitive and likely to make these problems persist  
> forever,
>     even more so than XSS and XSRF),
>
>  b) Does not break any plausible usage scenarios we could think of  
> (with
>     a particular attention to IFRAMEd non-same-origin document views,
>     ads, gadgets).

I think these are laudable goals, but I think you have failed to  
achieve (b).

>
>
> I would love to see better solutions along these lines to arise on  
> this forum; failing this, we may resort to a solution that requires  
> sites to opt in en masse for a particular mechanism, or to give up  
> defenses to permit certain types of applications to be built - but I  
> see this as suboptimal.
>
>> - Seems very difficult to validate correctness of the security  
>> policy.
>
> This one I'm not sure I follow; very few browser security mechanisms  
> are provable, and even the ones that are, usually do not get proven.  
> It is relatively easy to intuitively break down and analyze the  
> attack surface here, however.

I don't mean "validate" in the sense of a formal proof, I mean just in  
the sense of an informal but convincing argument. There are many ways  
to partially obscure or alter the contents of an iframe. Your original  
proposal missed the cases of altering opacity, scrolling the contents  
of the iframe, using filters to alter the frame's appearance, and  
probably more that we aren't thinking of. How about using a CSS  
transform to significantly alter the appearance? Or maybe there are  
pages where showing just the upper left to the user can be effective  
as an attack?

In other words, adopting this proposal would mean signing up for a  
game of security whack-a-mole.

>> - Likely to break user experience of some existing sites.
>
> Any particular examples?

For example, iGoogle widgets would become disabled if scrolled  
partially off the top of the page under your proposal. And even if  
scrolled back into view, would remain disabled for a second. With  
possibly a jarring visual effect, or alternately, no visual indication  
that they are disabled. Hard to decide which is worse.

Regards,
Maciej