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

OK, so it sounds like we don't need to take any action, as the spec already
allows for same-origin "interference" and therefore mutual compositing.


On Tue, Nov 19, 2013 at 2:28 PM, David Huang <linshung.huang@sv.cmu.edu>wrote:

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