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

Feedback on UI Safety draft

From: David Ross <dross@microsoft.com>
Date: Tue, 26 Feb 2013 18:41:44 +0000
To: "Brad Hill (bhill@paypal-inc.com)" <bhill@paypal-inc.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <824608aebb1d42a88aee68ca7b09fc96@SN2PR03MB047.namprd03.prod.outlook.com>
Some feedback on the 11/2012 working draft:

> Existing anti-clickjacking measures including frame-busting [FRAMEBUSTING] codes and X-Frame-Options 
> cannot be used to protect resources that are intended to be embedded by arbitrary origins, and are 
> insufficient to defend against timing-based attacks involving multiple windows instead of multiple frames.

This text should clarify that Allow-From enables X-FRAME-OPTIONS to protect resources intended to be embedded by arbitrary origins.  The case where the feature is insufficient is a sub-scenario.  (Where the origin of the clickjacking innermost frame is unable to filter bad origins without compromising the overall use case.)

The primary issue with frame-busting script is that it's not a declarative security feature where browser support implies defense of a real security guarantee.  This script is often recognized as best practice only because it seems to work.  When it _doesn't_ actually work there can be a real dilemma.

> This specification obsoletes X-Frame-Options.
...is inconsistent with...
> A user agent that understands the directives in this document SHOULD ignore the X-Frame-Options 
> header, when present, if User Interface Safety directives are also present in a Content-Security-Policy 
> header. This is to allow resources to only be embedded if the mechanisms described in this specification 
> are enforced, and more restrictive X-Frame-Options policies applied otherwise.

I don't think X-FRAME-OPTIONS can truly be labeled obsolete if it is still used for this purpose.

The security / privacy issue (#6) involving report-uri is very important.  I think you can provide information on if the origin matches the origin associated with the CSP, but that's about it.

> The 'top-only' keword with the frame-options directive is provided for compatible behavior with the 
> X-Frame-Options header, but it may allow attacks to be mounted if a trusted context embeds an 
> untrusted context, because that untrusted context may itself then re-embed a resource from the 
> same origin as the trusted context.

It may make sense to add a sentence pointing out that this is most relevant in scenarios with sandboxed frames.  I'm not sure the security guarantees provided around framing prior to the sandbox attribute were ever specified very well.

> Some resource owners may specify a restrictive policy forbidding embedding in user agents that only 
> understand X-Frame-Options but be more permissive with user agents that implement UI Safety directives. 
> User agents that are aware of but choose not to implement any of the heuristics in this document MAY 
> still ignore X-Frame-Options when presented in combination with UI Safety directives in a Content Security 
> Policy. For example, a browsing environment that deliberately chooses not to implement UI Safety features 
> because they interfere with assistive technologies SHOULD NOT deny users access to resources on this 
> account. User agents taking this stance SHOULD implement the unsafe attribute of the UIEvent interface as 
> this may be interrogated by client applications doing feature detection.

Earlier in the document we had effectively said, "If you understand UI Safety, feel free to ignore X-FRAME-OPTIONs."  But now we go on to say "If you know about UI Safety but don't actually implement it, also feel free to ignore X-FRAME-OPTIONS."  I suppose that makes sense and is the simplest to code, but it seems a little odd that you could specify both UI Safety and X-FRAME-OPTIONS on a page and then have both completely ignored, legitimately.

David Ross
dross@microsoft.com
Received on Tuesday, 26 February 2013 18:45:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 26 February 2013 18:45:25 GMT