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 protected]] Sent: Monday, September 03, 2012 10:26 AM To: Tobias Gondrom Cc: [email protected]; [email protected]; 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 protected]> wrote: > On 02/09/12 23:40, Adam Barth wrote: >> On Sun, Sep 2, 2012 at 4:40 AM, Tobias Gondrom >> <[email protected]> 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 _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
