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

[Tobias Gondrom <[e-mail]>]

On 02/09/12 23:40, Adam Barth wrote:
> On Sun, Sep 2, 2012 at 4:40 AM, Tobias Gondrom
> <[e-mail]> wrote:
>> 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.
> 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.

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?

>> 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.
>
>> 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"?
> 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 ","> )

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.

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

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.


>
> Adam