W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2008

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

From: Michal Zalewski <lcamtuf@dione.cc>
Date: Fri, 26 Sep 2008 00:23:24 +0200 (CEST)
Message-ID: <Pine.LNX.4.64.0809260007271.17562@dione.cc>
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. 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 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.

> - Likely to break user experience of some existing sites.

Any particular examples?

Cheers,
/mz
Received on Thursday, 25 September 2008 15:23:24 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:05 UTC