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