W3C home > Mailing lists > Public > public-web-security@w3.org > January 2011

Re: XSS mitigation in browsers

From: Michal Zalewski <lcamtuf@coredump.cx>
Date: Fri, 21 Jan 2011 09:25:29 -0800
Message-ID: <AANLkTim_fekeBkPOCNSVJU2TDQtNRTYZ6DvMVQSa_iHM@mail.gmail.com>
To: gaz Heyes <gazheyes@gmail.com>
Cc: Giorgio Maone <g.maone@informaction.com>, Daniel Veditz <dveditz@mozilla.com>, Brandon Sterne <bsterne@mozilla.com>, public-web-security@w3.org, Lucas Adamski <ladamski@mozilla.com>
>> Also, what if a frame is moved underneath the cursor just milliseconds
>> before the user clicks something - in which case, the tooltip appears
>> too late to allow for any meaningful reaction?
>
> JavaScript should not be able to control of iframes that have been allowed
> with x-frame-options.

That does not solve the problem; a frame can be repositioned by moving
around a <div> that contains it, or deleting / adding elements before
it. The ability to control page layout from JS level to this extent
appears to be essential to how the Internet works today.

>> What if the document is larger than window size? Can the frame be
>> rendered partly off-screen, so that only several pixes are still left
>> on the screen?
>
> The iframe shouldn't be rendered in any way off screen, it should either be
> centered or removed from display.

Keep in mind that this is a legitimate scenario; you can have a page
that is longer than window size, and has a scroll bar. From that
perspective, the first option is unacceptable: you don't want all
"like" buttons on a three-page document to appear out of place as you
scroll. The latter is perhaps possible, but causes flicker when you
scroll.

>> I can also imagine this colliding in nasty ways with things such as
>> drop-down lists or menus - you don't want "like" buttons to be drawn
>> on top of them :-(
>
> It's up to the dev to place the iframe in a place were it doesn't overlap,
> the iframe should always be higher than any other element IMO.

Again, consider non-malicious uses: let's say I'm on Flickr or
Youtube, and there is a drop-down menu with a list possible actions,
then "like"-able comments several hundred pixels below.

I don't think it's a very bad proposal, but it immediately runs into a
number of problems that are difficult to seamlessly account for, which
is why I haven't proposed it back in 2008 - opting for blocking input
to partly obstructed frames, instead. Even that got panned on
complexity and usability grounds; some of that criticism is knee-jerk,
but some is very much valid ;-)

Cheers,
/mz
Received on Friday, 21 January 2011 17:26:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 21 January 2011 17:26:23 GMT