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

[Adam Barth <[e-mail]>]

On Mon, Sep 3, 2012 at 9:35 AM, Tobias Gondrom
<[e-mail]> wrote:
> 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?

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.

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

There are none that I'm aware of.

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

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.

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

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

Adam