W3C home > Mailing lists > Public > public-webappsec@w3.org > July 2012

Coordinating Frame-Options and CSP UI Safety directives

From: Hill, Brad <bhill@paypal-inc.com>
Date: Mon, 9 Jul 2012 18:31:42 +0000
To: "public-webappsec@w3.org" <public-webappsec@w3.org>, "websec@ietf.org" <websec@ietf.org>
Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E1799AD@DEN-EXDDA-S12.corp.ebay.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 9 July 2012 18:32:16 GMT