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

From: Tobias Gondrom <[email-masked]>
Date: Sun, 02 Sep 2012 19:40:28 +0800

Hello all,

thank you for your feedback and input.

<hat="individual">

NIH (not invented here) should definitely never be reason for a decision 
- in either way.
And I would also be open to assist the WebAppSec WG in writing this tiny 
bit into CSP.

I have two main reasons why I think we should keep FO separate to CSP 
and would like to hear your thoughts about it before we should make a 
decision. (Please note that in the case of this topic I will obviously 
not be acting as WG chair.)

1. Model and Semantic Reason:
Until now, I always understood the CSP model to be about "describe the 
security policy for a loaded resource and say which parts of that 
content you can execute and which references in that content you shall 
follow and execute".
While the XFO/FO model is the reverse: describing for a resource, 
defining by whom your resource may be framed/loaded from. In my view 
that was not a natural part of the CSP model. And in my understanding 
that semantic difference was also one of the reasons why it was not done 
in CSP1.0 in the first place, but at the time agreed to be done in 
websec separately.

Or as someone else from W3C WebAppSec wrote it more clearly to me about 
a year ago:
"... removing frame-ancestors from CSP altogether if a better, 
standardized Frame-Options is available to sites. In fact, it simplifies 
the model in some ways since frame-ancestors is currently the only 
directive that restricts content from the embedded site's perspective."

2. Technical Implementation:
The current FO spec allows only one "Allow-From" URI. Which means that 
for complex framing relationships, the FO header needs to be 
written/sent on the fly on a per request basis.
My question is, what happens to only one "ALLOW-FROM" if we integrate it 
into CSP?
Can we generate individual CSPs on the fly as well (including if a CSP 
header references a file), or would this then implicitely mean we have 
to allow a list of "ALLOW-FROM"?

(please note, that the initial version did allow a list for 
"Allow-From", but there were serious concerns for performance in 
implementation for large lists and privacy matters. The change to only 
one "Allow-From" is not "written in stone", still I would like to 
understand if we limit ourselves back to the "Allow-From list" 
implicitly by putting it into CSP? I had a couple of private 
conversations on this problem in the last months, but they could not 
definitively answer to that question...)

Best regards, Tobias

---

From: Adam Barth <[email-masked]>
Date: Sun, 2 Sep 2012 08:40:44 -0700

On Sun, Sep 2, 2012 at 4:40 AM, Tobias Gondrom
<[email-masked]> wrote:
> NIH (not invented here) should definitely never be reason for a decision -
> in either way.
> And I would also be open to assist the WebAppSec WG in writing this tiny bit
> into CSP.
>
> I have two main reasons why I think we should keep FO separate to CSP and
> would like to hear your thoughts about it before we should make a decision.
> (Please note that in the case of this topic I will obviously not be acting
> as WG chair.)
>
> security policy for a loaded resource and say which parts of that content
> you can execute and which references in that content you shall follow and
> execute".
> While the XFO/FO model is the reverse: describing for a resource, defining
> by whom your resource may be framed/loaded from. In my view that was not a
> natural part of the CSP model. And in my understanding that semantic
> difference was also one of the reasons why it was not done in CSP1.0 in the
> first place, but at the time agreed to be done in websec separately.

Now that we're done with CSP 1.0, I think it make sense to take a more
expansive view of the sorts of security policies that can be expressed
in a Content-Security-Policy.  My view is that a security policy
expressed in CSP ought to have the following properties:

1) The policy should apply only to an individual resource
representation.  That means that the security policy is scoped to the
individual HTTP response and doesn't have broader-reaching effects
(e.g., about future HTTP responses).

2) The policy should only restrict privileges---not grant any
privileges.  That means that the security policy is useful for
implementing "least privilege": you can use it to drop privileges
you're not using (e.g., the ability to execute inline script) so that
an attacker can't trick you into using this privileges to your
detriment.

X-Frame-Options / Frame-Options fits nicely into this rubric.

> Or as someone else from W3C WebAppSec wrote it more clearly to me about a
> year ago:
> "... removing frame-ancestors from CSP altogether if a better, standardized
> Frame-Options is available to sites. In fact, it simplifies the model in
> some ways since frame-ancestors is currently the only directive that
> restricts content from the embedded site's perspective."

Having a simplified model has been very helpful to us over the past
year because it has let us finish CSP 1.0.  Now we're done with CSP
1.0 and looking at what the next step should be in CSP's evolution.

> The current FO spec allows only one "Allow-From" URI. Which means that for
> complex framing relationships, the FO header needs to be written/sent on the
> fly on a per request basis.
> header references a file), or would this then implicitely mean we have to
> allow a list of "ALLOW-FROM"?

Integrating with CSP imposes no technical restrictions in this regard.
 If you want to have only a single source, you can define the syntax
as:

directive-name = "frame-options"
directive-value = source-expression

Most other directives use source-list (which is just a list of
source-expressions), but there's no reason we can't do something
different here if that makes sense.  In fact, the only hard technical
restriction on the directive-value is that it conform to the following
ABNF:

directive-value   = *( WSP / <VCHAR except ";" and ","> )

> (please note, that the initial version did allow a list for "Allow-From",
> but there were serious concerns for performance in implementation for large
> lists and privacy matters. The change to only one "Allow-From" is not
> "written in stone", still I would like to understand if we limit ourselves
> back to the "Allow-From list" implicitly by putting it into CSP? I had a
> couple of private conversations on this problem in the last months, but they
> could not definitively answer to that question...)

I'm a bit surprised that you'd want to limit frame-options to having
only one source-expression, but we can discuss that point regardless
of whether we decide to integrate it with CSP.

Adam

---

From: Tobias Gondrom <[email-masked]>
Date: Tue, 04 Sep 2012 00:35:07 +0800

> X-Frame-Options / Frame-Options fits nicely into this rubric.

Well. Hm. I am not sure that I would agree that extending the CSP 
semantic model to the superset that then includes "defining by whom your 
resource may be framed/loaded from" instead of the current CSP1.0 model 
is necessarily a good thing. Maybe one question: If we extend the 
semantic of a system, it is always good if such extension is not for a 
group size of "1" (aka only one individual directive). Therefore my 
question: Are there other use cases (directives planned for 2.0) that 
require the same type of semantic extension or would FO be unique in 
that regard? If so, which semantic extensions would that be?

> directive-value   = *( WSP / <VCHAR except ";" and ","> )

Adam, I am sorry. I may not have been clear enough with my question.
My concern is not with regard of whether we can define such a directive 
(in my view this is trivial).
But the question is whether we can practically implement such, or 
whether there are implementation problems that would forbid (or 
seriously discourage) dynamic generation of a CSP on a per request 
basis? Because that would be the consequence of only one single 
"Allow-From" URI (instead of list).
Or to put it differently:
- Have there been successful and scaling implementations of CSP that 
have generated the CSP header on the fly for every request?
- If not, what would be the pitfalls/problems if we would do so?
- What are possible performance issues with that?
- And last but not least, is there a caching of CSP use case? (which 
could break if we generate the CSP file on the fly for every single 
request...)

If we move FO to CSP, I would like to know whether this will break (or 
due to implementation/scaling problems basically forbids) the current 
design of "Allow-From" _before_ we do so.

> of whether we decide to integrate it with CSP.

Actually, this was not my idea, but from Dave, who explained to me the 
performance and privacy implications when going with a (potentially 
long) list of allowed URIs. Personally, I could still see both ("list" 
or "single" URI), though I can understand the very serious concerns with 
"list".
We can discuss the FO design decision later, however, as explained 
above, if the choice to move FO into CSP basically pre-decides that we 
must then go with a "list" (for practical/implementation reasons), I 
would like to know and spell out this limitation rather now than later.

---

From: Adam Barth <[email-masked]>
Date: Mon, 3 Sep 2012 10:25:38 -0700

On Mon, Sep 3, 2012 at 9:35 AM, Tobias Gondrom
<[email-masked]> wrote:
>>> -
>>> bit
>>> defining
> Well. Hm. I am not sure that I would agree that extending the CSP semantic
> model to the superset that then includes "defining by whom your resource may
> be framed/loaded from" instead of the current CSP1.0 model is necessarily a
> good thing. Maybe one question: If we extend the semantic of a system, it is
> always good if such extension is not for a group size of "1" (aka only one
> individual directive). Therefore my question: Are there other use cases
> (directives planned for 2.0) that require the same type of semantic
> extension or would FO be unique in that regard? If so, which semantic
> extensions would that be?

I'm not sure I understood your question, but I'll try to answer it
anyway.  We're considering a number of new directives for CSP 1.1 that
aren't related to loading subresources.  For example, the form-action
directive is about restricting form submissions:

http://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#form-action--experimental

We've designed CSP to be extensible, as requested by
<http://tools.ietf.org/html/draft-hodges-websec-framework-reqs-02#section-7>.
 Frame-options falls well inside the scope we envision.

>>> standardized
>>> for
> My concern is not with regard of whether we can define such a directive (in
> my view this is trivial).
>
> But the question is whether we can practically implement such, or whether
> there are implementation problems that would forbid (or seriously
> discourage) dynamic generation of a CSP on a per request basis?

There are none that I'm aware of.

> Because that
> would be the consequence of only one single "Allow-From" URI (instead of
> list).
> - Have there been successful and scaling implementations of CSP that have
> generated the CSP header on the fly for every request?

I'm not aware of any in the public world, but I have seen (non-public)
implementations that construct the script-src whitelist dynamically
based on statically analyzing the HTML templates used to generate a
particular page.  You might imagine that this design would be
attractive in a system like Google Web Toolkit
<https://developers.google.com/web-toolkit/>, where the framework has
enough insight into how the app works to build a CSP policy.

> - If not, what would be the pitfalls/problems if we would do so?

There's nothing magical going on.  It's just as easy to generate a
Frame-Options header dynamically as it is to generate a frame-options
directive in a Content-Security-Policy header dynamically.

> - What are possible performance issues with that?

The performance considerations are the same regardless of whether
you're using a Frame-Options header or a frame-options directive in a
Content-Security-Policy header.  The two are isomorphic.

> - And last but not least, is there a caching of CSP use case? (which could
> break if we generate the CSP file on the fly for every single request...)

The Content-Security-Policy header is cached in exactly the same way
as the Frame-Options header.  There is nothing magical going on.

> If we move FO to CSP, I would like to know whether this will break (or due
> to implementation/scaling problems basically forbids) the current design of
> "Allow-From" _before_ we do so.

It will not.

> performance and privacy implications when going with a (potentially long)
> list of allowed URIs. Personally, I could still see both ("list" or "single"
> URI), though I can understand the very serious concerns with "list".
> We can discuss the FO design decision later, however, as explained above, if
> the choice to move FO into CSP basically pre-decides that we must then go
> with a "list" (for practical/implementation reasons), I would like to know
> and spell out this limitation rather now than later.

Moving to CSP does not imply an pre-decision on this topic.

Adam

---

From: David Ross <[email-masked]>
Date: Tue, 4 Sep 2012 05:06:39 +0000

There was a bit of discussion earlier on the list w.r.t. multi-origin vs. single-origin for allow-from.  I'm very much in favor of single origin.  Just imagine a few years from now seeing a policy or header with 1500 origins -- if we allow that to happen, it will happen.

So I'm very happy to hear we can specify the single-origin syntax as suggested below.  If we're going to go with CSP for FO, I'd feel most comfortable if we can get some confirmation that this is the POR.

I agree that serving dynamic policy shouldn't be technically difficult.  But I do worry about this in a larger sense.  It would be good to brainstorm implications of dynamic policy.  Is there any impact to platforms, design patterns, etc. that may have been imagined / planned during the course of CSP's development?  It just feels like a non-trivial change to the way CSP was thought out.

Dave

-----Original Message-----
From: Adam Barth [mailto:[email-masked]] 
Sent: Monday, September 03, 2012 10:26 AM
To: Tobias Gondrom
Cc: [email-masked]; [email-masked]; David Ross
Subject: Re: [websec] Coordinating Frame-Options and CSP UI Safety directives

On Mon, Sep 3, 2012 at 9:35 AM, Tobias Gondrom <[email-masked]> wrote:
>>> And I would also be open to assist the WebAppSec WG in writing this 
>>> tiny bit into CSP.
>>>
>>> I have two main reasons why I think we should keep FO separate to 
>>> CSP and would like to hear your thoughts about it before we should 
>>> make a decision.
>>> (Please note that in the case of this topic I will obviously not be 
>>> acting as WG chair.)
>>>
>>> Until now, I always understood the CSP model to be about "describe 
>>> the security policy for a loaded resource and say which parts of 
>>> that content you can execute and which references in that content 
>>> you shall follow and execute".
>>> that was not a natural part of the CSP model. And in my 
>>> understanding that semantic difference was also one of the reasons 
>>> why it was not done in CSP1.0 in the first place, but at the time 
>>> agreed to be done in websec separately.
>>
>> Now that we're done with CSP 1.0, I think it make sense to take a 
>> more expansive view of the sorts of security policies that can be 
>> expressed in a Content-Security-Policy.  My view is that a security 
>> policy expressed in CSP ought to have the following properties:
>>
> semantic model to the superset that then includes "defining by whom 
> your resource may be framed/loaded from" instead of the current CSP1.0 
> model is necessarily a good thing. Maybe one question: If we extend 
> the semantic of a system, it is always good if such extension is not 
> for a group size of "1" (aka only one individual directive). Therefore 
> my question: Are there other use cases (directives planned for 2.0) 
> that require the same type of semantic extension or would FO be unique 
> in that regard? If so, which semantic extensions would that be?

I'm not sure I understood your question, but I'll try to answer it anyway.  We're considering a number of new directives for CSP 1.1 that aren't related to loading subresources.  For example, the form-action directive is about restricting form submissions:

We've designed CSP to be extensible, as requested by <http://tools.ietf.org/html/draft-hodges-websec-framework-reqs-02#section-7>.
 Frame-options falls well inside the scope we envision.

>>> Or as someone else from W3C WebAppSec wrote it more clearly to me 
>>> about a year ago:
>>> standardized Frame-Options is available to sites. In fact, it 
>>> simplifies the model in some ways since frame-ancestors is currently 
>>> the only directive that restricts content from the embedded site's 
>>> perspective."
>>
>>> The current FO spec allows only one "Allow-From" URI. Which means 
>>> that for complex framing relationships, the FO header needs to be 
>>> My question is, what happens to only one "ALLOW-FROM" if we 
>>> integrate it into CSP?
>>> Can we generate individual CSPs on the fly as well (including if a 
>>> CSP header references a file), or would this then implicitely mean 
>>> we have to allow a list of "ALLOW-FROM"?
>>
> My concern is not with regard of whether we can define such a 
> directive (in my view this is trivial).
>
> seriously

> Because that
> would be the consequence of only one single "Allow-From" URI (instead 
> of list).

I'm not aware of any in the public world, but I have seen (non-public) implementations that construct the script-src whitelist dynamically based on statically analyzing the HTML templates used to generate a particular page.  You might imagine that this design would be attractive in a system like Google Web Toolkit <https://developers.google.com/web-toolkit/>, where the framework has enough insight into how the app works to build a CSP policy.

> - If not, what would be the pitfalls/problems if we would do so?

There's nothing magical going on.  It's just as easy to generate a Frame-Options header dynamically as it is to generate a frame-options directive in a Content-Security-Policy header dynamically.

> - What are possible performance issues with that?

The performance considerations are the same regardless of whether you're using a Frame-Options header or a frame-options directive in a Content-Security-Policy header.  The two are isomorphic.

> could break if we generate the CSP file on the fly for every single 

The Content-Security-Policy header is cached in exactly the same way as the Frame-Options header.  There is nothing magical going on.

It will not.

>>> implementation for large lists and privacy matters. The change to 
>>> only one "Allow-From" is not "written in stone", still I would like 
>>> to understand if we limit ourselves back to the "Allow-From list" 
> long) list of allowed URIs. Personally, I could still see both ("list" or "single"

Adam

---

From: Adam Barth <[email-masked]>
Date: Mon, 3 Sep 2012 22:28:02 -0700

> So I'm very happy to hear we can specify the single-origin syntax as suggested below.  If we're going to go with CSP for FO, I'd feel most comfortable if we can get some confirmation that this is t…

I certainly happy to take that as the starting point.  I'd still like
to have a discussion about the pros and cons, but if the pros outweigh
the cons, I don't have a strong objection to having only a single
origin.

> I agree that serving dynamic policy shouldn't be technically difficult.  But I do worry about this in a larger sense.  It would be good to brainstorm implications of dynamic policy.  Is there any i…

I had always sort of assumed folks would dynamically generate their
CSP policy because authors policy by hand is somewhat of a pain.  If
you have any specific concerns, I'm happy to discuss them.

Adam