Re: [websec] Coordinating Frame-Options and CSP UI Safety directives

[Tobias Gondrom <[e-mail]>]

Brad,

thank you for your email.

<hat="individual">

Reading your argument, I think it would be very helpful to hear in more 
detail from you the concrete reasons for why you think the current 
solution is weak and why it would be better in CSP.
Answering to your mentioned arguments:
1. IMHO "save on some header bloat" is a very weak argument, that on the 
one hand is not a big problem looking at the current header landscape 
and could be used to basically wrap everything from HSTS headers to 
whatever into CSP, which then leads to a huge meta-header (or some might 
call it "CSP bloat" ;-) ).
2. I think the migration from XFO to FO is straight forward, in fact I 
rather see a complication (disadvantage) by moving it to the CSP model 
instead of a direct evolution path from XFO to FO.

And actually as I also already described in a previous argument on 
websec, the FO functionality is not fully symmetric to all other CSP 
directives, and therefore should not be handled in CSP.

In summary, I do think FO would be better to continue as a draft in 
Websec and can not see any significant benefit in moving it into CSP. 
Could you please provide some more specific reasons or examples about 
why exactly FO might be better as part of CSP?

Best regards, Tobias


Ps.: please note, that I am currently on holiday and will only be able 
to answer emails in about a weeks time.



On 09/07/12 19:31, Hill, Brad wrote:
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/websec