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 _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
