[whatwg] Dealing with UI redress vulnerabilities inherent to the current web
mjs at apple.com
Thu Sep 25 20:07:55 PDT 2008
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-
> mechanisms (all things aside, placing the burden on server side is
> counterintuitive and likely to make these problems persist
> even more so than XSS and XSRF),
> b) Does not break any plausible usage scenarios we could think of
> 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
> 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
> 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.
More information about the whatwg