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

Adam Barth <> Tue, 04 September 2012 05:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1485521F8499 for <>; Mon, 3 Sep 2012 22:28:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AQHtHDU6zO6l for <>; Mon, 3 Sep 2012 22:28:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7189221F847F for <>; Mon, 3 Sep 2012 22:28:35 -0700 (PDT)
Received: by eaai11 with SMTP id i11so1785708eaa.31 for <>; Mon, 03 Sep 2012 22:28:34 -0700 (PDT)
Received: by with SMTP id g48mr24652312eeo.45.1346736514399; Mon, 03 Sep 2012 22:28:34 -0700 (PDT)
Received: from ( []) by with ESMTPS id k41sm42114890eep.13.2012. (version=SSLv3 cipher=OTHER); Mon, 03 Sep 2012 22:28:32 -0700 (PDT)
Received: by eaai11 with SMTP id i11so1785703eaa.31 for <>; Mon, 03 Sep 2012 22:28:32 -0700 (PDT)
Received: by with SMTP id c42mr24779960eeo.35.1346736512246; Mon, 03 Sep 2012 22:28:32 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 3 Sep 2012 22:28:02 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
From: Adam Barth <>
Date: Mon, 03 Sep 2012 22:28:02 -0700
Message-ID: <>
To: David Ross <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [websec] Coordinating Frame-Options and CSP UI Safety directives
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 04 Sep 2012 05:28:37 -0000

On Mon, Sep 3, 2012 at 10:06 PM, David Ross <> wrote:
> 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 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

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

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.


> -----Original Message-----
> From: Adam Barth []
> Sent: Monday, September 03, 2012 10:26 AM
> To: Tobias Gondrom
> Cc:;; David Ross
> Subject: Re: [websec] Coordinating Frame-Options and CSP UI Safety directives
> On Mon, Sep 3, 2012 at 9:35 AM, Tobias Gondrom <> wrote:
>> On 02/09/12 23:40, Adam Barth wrote:
>>> On Sun, Sep 2, 2012 at 4:40 AM, Tobias Gondrom
>>> <> 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:
> We've designed CSP to be extensible, as requested by <>.
>  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 <>, 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