W3C home > Mailing lists > Public > public-webappsec@w3.org > November 2013

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

From: Giorgio Maone <g.maone@informaction.com>
Date: Tue, 19 Nov 2013 22:42:08 +0100
Message-ID: <528BDB30.9050700@informaction.com>
To: public-webappsec@w3.org
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
Received on Tuesday, 19 November 2013 21:42:31 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:03 UTC