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
