On 10/22/09 3:02 PM, Collin Jackson wrote: > On Thu, Oct 22, 2009 at 2:22 PM, Brandon Sterne <[email protected]> wrote: >> 1. Splitting the modules based upon different threat models doesn't seem to >> be the right approach. There are many areas where the threats we want to >> mitigate overlap in terms of browser functionality. A better approach, >> IMHO, is to create the modules based upon browser capabilities. With those >> capability building blocks, sites can then construct policy sets to address >> any given threat model (including ones we haven't thought of yet). > > Would that mean that each module would have multiple directives, with > a separate threat model for each one? It seems like the directives > should be granular to the level of threat models, or else a site will > be forced to give up functionality to defend against threats it's not > concerned about.
I imagine each module would have its own directives, though not necessarily more than one. If the modules are based on browser capabilities, then it is possible to map these capabilities to threat mitigations. If we try to do the reverse, that is, map threat mitigations to CSP modules, we run the risk of having particular browser capabilities governed by multiple, potentially conflicting, modules. Take XSS and history stealing for example. Assume these are seperate modules and each is responsible for mitigating its respective threat. Presumably the safe history module will prevent a site from being able to do getComputedStyle (or equivalent) on a link from a different origin. But an attacker could still steal history from any site that he can inject script into by document.writing the list of URLs into the page, testing if they are visited, and sending the results back to the attacker's site. Granted, this is a contrived example and the attacker could probably do worse than history stealing if we're allowing that he can inject arbitrary script. But the point is that the threat of history stealing is not fully mitigated by changes to CSS for cross-origin links. A complete mitigation of the threat requires both altering the behavior of getComputedStyle as well as disabling non-trusted scripts in the document. Given sufficient granularity in browser capabilities, it is fairly easy to build a policy to address any particular threat model. Starting from the threat and working backwards seems to me to force sites to accept restrictions which may be unexpected or non-intuitive. >> 2. The original goal of CSP was to mitigate XSS attacks. The scope of the >> proposal has grown substantially, which is fine, but I'm not at all >> comfortable with a product that does not require the XSS protections as the >> fundamental core of the model. I think if we go with the module approach, >> the XSS protection needs to be required, and any additional modules can be >> optionally implemented. > > I think it makes sense to have modules that are required for browser > vendos to implement, but are not required for web authors to enable. > Is that what you mean? We could make the XSSModule "required" for > browser vendors to implement instead of just "recommended." I don't, > however, think that a web author should be required to use the > XSSModule in order to benefit from the ClickJackingModule (for > example). I agree completely with this. "Required" module would apply to browser vendors only. Sites would not be required to utilize any particular module, but they would be guaranteed that any required module will be present in every CSP implementation. >> I propose that the default behavior for CSP (no >> optional modules implemented) is to block all inline scripts (opt-in still >> possible) and to use a white list for all sources of external script files. > > I understand the desire to have "by-default" security, but one problem > with opt-out CSP rules is that they're hard to change. You can't add > new opt-out rules in the future because it will break web sites that > didn't know they were supposed to opt out, so we'd be stuck with an > initial set of opt-out rules and any rules added in future versions of > the spec would have to be opt-in. Also, it's tricky to change an > opt-out rule to be an opt-in rule in the future because web sites may > be relying on the opt-out behavior. "By-default" security is definitely the motivation for the opt-in mechanism currently proposed. I see how a change from opt-in to opt-out in the future would be impossible, because lots of sites who were once safe suddenly lose protection. I also see that changing from opt-out to opt-in would be slightly better: you would have some sites intending to use inline scripts suddenly break, but they would likely be no less secure by turning off the scripts. Why, though, would we ever want to change from an opt-in to an opt-out model? If we agree now (and I'm not assuming we all do) that opting-in to potentially dangerous features is a better model, what could change in the Web environment that would make that decision no longer appropriate? > If there are a set of behaviors that make sense when used together, > then maybe providing a concise opt-in directive that enables them all > would be easier, e.g. "core-xss". I think it's better to have sites be explicit with their policies, as it forces them to understand the implications of each part of the policy. If we provide pre-canned policies, sites may wind up with incorrect assumptions about what is being restricted. >> I'm definitely not opposed to splitting apart the spec into modules, >> especially if it helps other browser implementers move forward with CSP. I >> REALLY think, though, that the XSS protections need to be part of the base >> module. > > Could you elaborate a little more on why you feel this way? This seems > like a major extensibility limitation that would be impossible to > change in the future. As we discussed above, no site would be required to use the anti-XSS features. They could opt not to use those features. The situation I want to avoid is having browsers advertise (partial) CSP support and have websites incorrectly assume that they are getting XSS protection from those browsers. Also, it seems unlikely to me that successful mitigations can be put in place for the other threats if XSS is still possible (I can provide examples if people are interested, but I have to run to catch a train, unfortunately). If we can agree that XSS is the main threat that we want to address with CSP, then I think we can also agree to make it a required module. -Brandon (Really appreciate everyone's feedback, BTW) _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
