- From: Giorgio Maone <g.maone@informaction.com>
- Date: Tue, 19 Nov 2013 22:42:08 +0100
- 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