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

[Adam Barth <[e-mail]>]

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.

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

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