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

From: "Hill, Brad" <[email-masked]>
Date: Mon, 9 Jul 2012 18:31:42 +0000

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

---

From: Tobias Gondrom <[email-masked]>
Date: Tue, 10 Jul 2012 00:23:26 +0100

Brad,

thank you for your email.

<hat="WG chair">

I agree that, now that WebAppSec is finally also operational, we maybe 
should revive the discussion between WebAppSec and Websec about what 
topics should be done where. Either on WG level, or initially on WG 
chair level to develop a proposal to present to the WGs to decide on. 
Please note, this coordination goes both ways: discussing which features 
should be done in WebAppSec and which should better be done in Websec.

This may also mean we revive the discussion we had on where to do 
Frame-Options.

But just to be clear about the facts of the current status, it seems I 
need to correct one of your statements in your email, which may 
otherwise be a little bit misleading:
(Fortunately, I keep all my communication emails and minutes well 
preserved in an archive to be later able to refresh my memory. ;-) )
In fact, initially, between the founded Websec WG  and the still nascent 
WebAppSec WG the communication was already clearly about how to go 
forward with Frame-Options (removing the "X-" and improvements) and 
doing that in Websec and the conclusion at that time then was to do it 
as a draft in websec and not in CSP, which evidently happened as it was 
removed from the initial CSP draft and the frame-options draft was 
created. This was not about documenting the current behaviour as you 
might suggest in your email, if I read your statement correctly.
In fact, it was only recently, a couple of months ago, that actually 
Thomas Roessler and Jeff Hodges proposed to also document the existing 
(old/current) behaviour of X-Frame-Options in addition to the worked on 
Frame-Options draft in one of our IETF WebSec WG meetings - see here: 
http://www.ietf.org/proceedings/81/minutes/websec.txt  Only as a 
consequence of that we started the X-Frame-Options draft to document the 
current behaviour, too.

However, of course any past decision to do FO in websec does not 
necessarily mean it would be the only option forward to keep FO 
(Frame-Options) in WebSec.

FYI: After the Frame-Options (and X-Frame-Options) drafts were initially 
handled as individual submissions, the WebSec WG adopted the documents 
as WG drafts:
tools.ietf.org/html/draft-ietf-websec-frame-options-00
(previously: http://tools.ietf.org/html/draft-gondrom-frame-options-02)
tools.ietf.org/html/draft-ietf-websec-x-frame-options-00
(previously: http://tools.ietf.org/html/draft-gondrom-x-frame-options-02)

If you feel Websec is not the right place for FO and that this should 
instead be integrated into CSP (and possibly moved to WebAppSec), it is 
ok to have that discussion, again. However, based on the past decisions 
and the current status, I like to invite you to lead this discussion 
about possibly moving FO from Websec to WebAppSec primarily on the 
Websec WG mailing-list, as running one discussion on two separate 
mailing-lists can be confusing at best.

Thank you,

Tobias
(co-chair of websec)

On 09/07/12 19:31, Hill, Brad wrote:
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec

---

From: Tobias Gondrom <[email-masked]>
Date: Tue, 10 Jul 2012 00:33:40 +0100

Brad,

<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.

---

From: "Hill, Brad" <[email-masked]>
Date: Tue, 10 Jul 2012 00:02:31 +0000

Tobias,

 I'm happy to move the discussion primarily to websec, and I'll drop the cc: to webappsec after this email.  Thanks for the historical clarification, as well.

I'm not terribly concerned about which group does the work, as much as arriving at the engineering solution that works best for user agent and resource authors, some of whom have expressed preference for moving this functionality into CSP.  As both a chair and an individual, I don't have a strong preference, but I think there are reasons in favor of each option and it is worth re-opening the discussion now that the WebAppSec WG has a concrete deliverable under development to address the same general class of attacks.

I'll send out a summary shortly of the similarities and differences between the various options currently proposed for some additional context.

-Brad Hill

---

From: David Ross <[email-masked]>
Date: Thu, 12 Jul 2012 00:22:12 +0000

Responding to a few of the points in Brad's original mail on this thread...

My concern is mostly around the degree to which a move to CSP might complicate or stall the process.  I'd also prefer not to see additional use cases pop up (eg: click fraud prevention) that just were never in scope before.

I think that w.r.t. header bloat, the most sensible approach is to only allow one origin to be specified.  CSP by-design facilitates the use of multiple origins.  As we've discussed w/Frame-Options, there is a design pattern to make the more basic single-origin approach functional.  I would hate to see hosts serving up source lists of hundreds of origins, just because they can.  I think that is exactly what will happen if we support multiple origins.

With regard to obsolescence of X-FRAME-OPTIONS, it's easy to specify exactly what happens in the FRAME-OPTIONS spec.  I don't see that CSP inherently improves on that but I may be missing something there.

The advantage I see of bringing FRAME-OPTIONS into CSP is that it makes CSP more comprehensive.  But I suspect there are plenty of other header-related security features that aren't defined by CSP (eg: the origin header, cookie security).

Finally, as Brad pointed out in the rosetta stone thread, Frame-Options provides the flexibility to perform only a top level origin check as opposed to a full ancestor check.  (Specified via the "AllAncestors" flag.)

David Ross
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hill, Brad
Sent: Monday, July 09, 2012 5:03 PM
To: Tobias Gondrom; [email-masked]
Cc: [email-masked]
Subject: Re: [websec] Coordinating Frame-Options and CSP UI Safety directives

Tobias,

-Brad Hill

---

From: Adam Barth <[email-masked]>
Date: Wed, 18 Jul 2012 16:17:02 -0700

Here are two reasons we should make Frame-Options into a
Content-Security-Policy directive rather than
yet-another-one-off-HTTP-header:

1) By centralizing all the policy bits in one string, we gain network
benefits.  For example, in the Chrome extension system, we have a field in
the manifest for specifying a Content Security Policy:

http://code.google.com/chrome/extensions/contentSecurityPolicy.html

While we could add a new attribute for every different bit of policy, it's
better for developers if there's just one place that contains the security
policy.

2) By moving Frame-Options into CSP, we can use the same origin-specifying
machinery that already exists in CSP rather than inventing
yet-another-way-of-specifying origins (e.g., in allow-from in the current
Frame-Options draft).  By doing that, we make all these things work the
same way rather than siloing each off depending on which browser vendor
first decided this bit of policy was interesting.

As far as I can tell, the main reason for not making Frame-Options a CSP
directive is that CSP was Not Invented Here.

Adam

On Wed, Jul 11, 2012 at 5:22 PM, David Ross <[email-masked]> wrote:

> My concern is mostly around the degree to which a move to CSP might
> complicate or stall the process.  I'd also prefer not to see additional use
> cases pop up (eg: click fraud prevention) that just were never in scope
> before.
>
> I think that w.r.t. header bloat, the most sensible approach is to only
> allow one origin to be specified.  CSP by-design facilitates the use of
> multiple origins.  As we've discussed w/Frame-Options, there is a design
> pattern to make the more basic single-origin approach functional.  I would
> hate to see hosts serving up source lists of hundreds of origins, just
> because they can.  I think that is exactly what will happen if we support
> multiple origins.
>
> With regard to obsolescence of X-FRAME-OPTIONS, it's easy to specify
> exactly what happens in the FRAME-OPTIONS spec.  I don't see that CSP
> inherently improves on that but I may be missing something there.
>
> The advantage I see of bringing FRAME-OPTIONS into CSP is that it makes
> CSP more comprehensive.  But I suspect there are plenty of other
> header-related security features that aren't defined by CSP (eg: the origin
> header, cookie security).
>
> Finally, as Brad pointed out in the rosetta stone thread, Frame-Options
> provides the flexibility to perform only a top level origin check as
> opposed to a full ancestor check.  (Specified via the "AllAncestors" flag.)
>
> David Ross
> [email-masked]
>
>
>  I'm happy to move the discussion primarily to websec, and I'll drop the
> cc: to webappsec after this email.  Thanks for the historical
> clarification, as well.
>
> I'm not terribly concerned about which group does the work, as much as
> arriving at the engineering solution that works best for user agent and
> resource authors, some of whom have expressed preference for moving this
> functionality into CSP.  As both a chair and an individual, I don't have a
> strong preference, but I think there are reasons in favor of each option
> and it is worth re-opening the discussion now that the WebAppSec WG has a
> concrete deliverable under development to address the same general class of
> attacks.
>
> I'll send out a summary shortly of the similarities and differences
> between the various options currently proposed for some additional context.
>
> -Brad Hill
>
>
>
>

---

From: David Ross <[email-masked]>
Date: Thu, 19 Jul 2012 19:51:14 +0000

#1 - fair point
#2 - I was worried that the current mechanism was multi-origin only, but it sounds like that's not the case.  If so, this is good.

NIH doesn't sound like a great reason at all.

Question for Tobias -- with a move to push this from the IETF to the W3C/CSP, given your IETF affiliation would you still be able to contribute time to this project?  (Sorry if that's an exceedingly blunt question, I'm not trying to step on toes here.)  Your work here thus far has been absolutely invaluable and has allowed XFO/FO to make forward progress with very little overhead.  I really don't want to lose the momentum.

Dave

From: Adam Barth [mailto:[email-masked]]
Sent: Wednesday, July 18, 2012 4:17 PM
To: David Ross
Cc: Hill, Brad; Tobias Gondrom; [email-masked]
Subject: Re: [websec] Coordinating Frame-Options and CSP UI Safety directives

Here are two reasons we should make Frame-Options into a Content-Security-Policy directive rather than yet-another-one-off-HTTP-header:

1) By centralizing all the policy bits in one string, we gain network benefits.  For example, in the Chrome extension system, we have a field in the manifest for specifying a Content Security Policy:

While we could add a new attribute for every different bit of policy, it's better for developers if there's just one place that contains the security policy.

2) By moving Frame-Options into CSP, we can use the same origin-specifying machinery that already exists in CSP rather than inventing yet-another-way-of-specifying origins (e.g., in allow-from in the current Frame-Options draft).  By doing that, we make all these things work the same way rather than siloing each off depending on which browser vendor first decided this bit of policy was interesting.

As far as I can tell, the main reason for not making Frame-Options a CSP directive is that CSP was Not Invented Here.

Adam

On Wed, Jul 11, 2012 at 5:22 PM, David Ross <[email-masked]<mailto:[email-masked]>> wrote:
Responding to a few of the points in Brad's original mail on this thread...

David Ross
[email-masked]<mailto:[email-masked]>

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Hill, Brad
Sent: Monday, July 09, 2012 5:03 PM
To: Tobias Gondrom; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [websec] Coordinating Frame-Options and CSP UI Safety directives

Tobias,

-Brad Hill

_______________________________________________
websec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/websec

_______________________________________________
websec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/websec

---

From: Thomas Roessler <[email-masked]>
Date: Fri, 20 Jul 2012 13:54:54 +0200

I wouldn't expect major obstacles from the W3C side to having Tobias participate there.
--
Thomas Roessler, W3C  <[email-masked]>  (@roessler)

On 2012-07-19, at 21:51 +0200, David Ross wrote:

> #1 – fair point
> #2 – I was worried that the current mechanism was multi-origin only, but it sounds like that’s not the case.  If so, this is good.
>  
> NIH doesn’t sound like a great reason at all.
>  
> Question for Tobias -- with a move to push this from the IETF to the W3C/CSP, given your IETF affiliation would you still be able to contribute time to this project?  (Sorry if that’s an exceedingly blunt question, I’m not trying to step on toes here.)  Your work here thus far has been absolutely invaluable and has allowed XFO/FO to make forward progress with very little overhead.  I really don’t want to lose the momentum.
>  
> Dave
>  
>