Re: XSS mitigation in browsers

On 21 January 2011 17:25, Michal Zalewski <lcamtuf@coredump.cx> wrote:

> >> 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.
>
>
Yeah that's the problem as it stands today but I'm proposing a different
behaviour for iframes in general when the x-frames-option header is applied
to allow framing. Moving a parent div would count as dynamic styling of the
iframe. The iframe could there stay where it is or be removed from display.



> 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 ;-)
>

These are awesome points :) I'm simply listing a possible solution and
you're breaking it apart which is good, the next stage is to work out
suitable solutions to all points raised. I'm in favour of a complete iframe
behaviour change but it seems you're against it as it breaks the current way
we display content on the web.