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
