Coordinating Frame-Options and CSP UI Safety directives

Tobias, David and other WebSec participants,

 Over at the W3C WebAppSec WG we are beginning to draft a set of new directives for Content Security Policy focused specifically on User Interface Safety - protection against clickjacking and other UI Redressing attacks.

 As Adam Barth suggested on this list a few weeks ago, WebSec and WebAppSec should discuss and coordinate on whether new functionality related to UI embedding, such as ALLOW-FROM or embed-ancestors, would be best developed as CSP directives or in a new Frame-Options header.  

 It made sense for the IETF WebSec group to be the lightest and fastest process to specify the existing behavior of X-Frame-Options, but further refinements are more in the realm of web user agent behavior.  If sites are going to specify UI safety directives using CSP, using that mechanism rather than a new Frame-Options header can save on some header bloat, as well as making it easier to interpret scenarios where a resource wants to obsolete the X-Frame-Options when new behaviors are available. (e.g., allow embedding if CSP UI Safety directives are understood, but deny it for user agents that only understand X-Frame-Options)

The current editor's draft doesn't include these options, but please take a look.  

http://dvcs.w3.org/hg/user-interface-safety/raw-file/tip/user-interface-safety.html 

A proposed additional directive for this specification is:

embed-ancestors

The embed-options directive indicates whether the user-agent should embed the resource using a frame, iframe, object or embed tag, or equivalent functionality in non-HTML resources. Resources can use this to avoid many UI Redressing attacks by ensuring they are not embedded into other sites. This directive replicates some of the functionality of the X-Frame-Options header. The syntax for the name and value of the directive are described by the following ABNF grammar:

directive-name    = "embed-ancestors"
directive-value   = source-list

Unlike policies defined in Content Security Policy 1.0, the embed-ancestors directives is not subject to the default-src directive. If this directive is not explicitly stated in the policy its value is assumed to be "*". 

If 'deny' is present in the source-list, the resource cannot be displayed in an embedded context, regardless of the origin attempting to do so, and all other members of the source-list are ignored. This provides functionality equivalent to the DENY value of the X-Frame-Options header.

If 'deny' is not present the source-list indicates which origins are valid ancestors for the resource. An ancestor is any resource between the protected resource and the top of the window frame tree; for example, if A embeds B which embeds C, both A and B are ancestors of C. If A embeds both B and C, B is not an ancestor of C, but A still is.

The 'self' source indicates that content of the same-origin as the protected resource may embed it. This provides functionality equivalent to the SAMEORIGIN value of the X-Frame-Options header.


Thank you - we welcome your thoughts and feedback,

 Brad Hill
Co-chair, W3C WebAppSec WG

Received on Monday, 9 July 2012 18:32:15 UTC