On Mon, Sep 3, 2012 at 10:06 PM, David Ross <[email protected]> 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 origin. > 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. Adam > -----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
