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

Re: XSS mitigation in browsers

From: gaz Heyes <gazheyes@gmail.com>
Date: Fri, 21 Jan 2011 10:15:44 +0000
Message-ID: <AANLkTimz-ojnoynjOo-FV1Q98S9N43MC4FVctBGb7Cv1@mail.gmail.com>
To: Michal Zalewski <lcamtuf@coredump.cx>
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>
On 21 January 2011 09:35, Michal Zalewski <lcamtuf@coredump.cx> wrote:

> What if there are several overlapping frames that meet this criteria
> all at the same time? There is only one "top" :-)

Overlapping iframes should both be disabled and removed from view.

> 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. We created a monster with iframes, it should be locked
down. Maybe some JS should be allowed but events and dynamic styles should
be prevented.

> 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. If the window height or width is below a
certain value then the iframe should be removed from display.

> 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.
Received on Friday, 21 January 2011 10:16:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:18 UTC