Re: webappsec-ISSUE-55 (input-protection and seamless iframes): How to handle seamless flag for input-protection policies? [UI Security]

Same here.

Cross-origin seamless iframe is fundamentally dangerous (see security
concerns in http://wiki.whatwg.org/wiki/AllowSeamless), including threats
(e.g. dimension information leaking) that are not in scope of UI Security.

So, assuming that cross-origin seamless iframes, if ever allowed, will be
guarded by some other origin-based opt-in mechanism, I vote that CSS
cascading and inheritance should always be respected as is in UI Security,
and no special behavior needs to be specified for seamless iframes.



On Tue, Nov 19, 2013 at 1:42 PM, Giorgio Maone <g.maone@informaction.com>wrote:

> On 31/10/2013 19:19, Web Application Security Working Group Issue
> Tracker wrote:
> > webappsec-ISSUE-55 (input-protection and seamless iframes): How to
> handle seamless flag for input-protection policies? [UI Security]
> >
> > http://www.w3.org/2011/webappsec/track/issues/55
> >
> > Raised by: Brad Hill
> > On product: UI Security
> >
> > Should we prohibit displaying content with an input-protection policy in
> a seamless iframe?  Because CSS gets cascaded into such a frame, it
> arguably already has no UI integrity from it's parent - but seamless also
> already requires that the parent be same-origin.
> Personally I'd like to just specify that input-protection policies apply
> to cross-origin embeddings only (i.e. the directives get ignored if the
> embedded document, the embedder *and all its ancestors* are
> same-origin): this way we would keep things simple and consistent, with
> no special behavior specified for seamless iframes.
> BUT we may imagine an (unlikely?) attack where a page loading seamless
> iframes based on user input is exploited by a further ancestor to weaken
> input protection on the seamlessly embedded subdocument (by displacing
> its elements' positions thanks to an unintended CSS pollution).  Such a
> page would be already in a not so firm security position by itself (sort
> of an open redirector), and it should at least use a restrictive
> "frame-options" directive on its side. However if we want to enforce
> this restriction and guard against such a scenario, we should treat
> input-protection at least as "frame options 'self'", if not 'deny',
> whenever the document is embedded in seamless iframe.
>
> -- G
>
>