On 10/27/09 4:32 PM, Adam Barth wrote: > On Tue, Oct 27, 2009 at 3:54 PM, Brandon Sterne <bste...@mozilla.com> wrote: >> My main objection to this approach is that it turns the whitelist approach >> we started with into a hybrid whitelist/blacklist. > > The design is a pure blacklist. Just like turning off unused > operating system services, content restrictions should let web > developers turn off features they aren't using.
I find it rather surreal that we are arguing over whether to implement a whitelist or a blacklist in CSP. I am strongly in the whitelist camp and I have seen no strong evidence that reversing the approach is the right way to go. Are there others who honestly feel a blacklist is a wise approach? >> The proposal doesn't >> support the simple use case of a site saying: >> "I only want the following things (e.g. script and images from myself). >> Disallow everything else." > > The problem is that "everything else" is ill-defined. I disagree completely. It's "the things I haven't explicitly approved". > Should we turn > off canvas? That's a "thing" that's not a script or an image from > myself. So are objects, stylesheets and every other type of content we have enumerated a policy directive for. We can add other directives if we think there is value in doing so for specific browser capabilities. > CSP, as currently design, as a hard-coded universe of > "things" it cares about, which limits its use as a platform for > addressing future use cases. It is a poor protocol that doesn't plan > for future extensibility. The list of "things" needs to be hard coded whether or not we allow sites to opt-in or opt-out of using them. Do you have any support for your claim that we don't plan for future extensibility? Our proposal is clear that browsers should skip over directives they don't understand which allows for new directives to be added in the future. >> Under your proposal, this site needs to explicitly opt-out of every >> directive, including any new directives that get added in the future. > > Not really. When we invent new directives, sites can opt in to them > by adding them to their policy. Just like you can opt in to new HTML5 > features by adding new HTML tags to your document. Remember the use case I gave as an example. Site wants X and Y and nothing more. In your model, not only _can_ sites add new policy as we add new directives, they _have to_ if they want to restrict themselves to X and Y. >> We're >> essentially forcing sites to maintain an exhaustive blacklist for all time >> in order to avoid us (browsers) accidentally blocking things in the future >> that the site forgot to whitelist. > > Web developers are free to ignore CSP directives that mitigate threats > they don't care about. There is no need for web developers to > maintain an exhaustive list of anything. Again, they do if they want to strictly whitelist the types of content in their site. >> Under your proposed model, a site will continue to "function correctly" only >> in the sense that nothing will be blocked in newer implementations of CSP >> that wouldn't also have been blocked in a legacy implementation. > > That's correct. The semantics of a given CSP policy does not change > as new directives are invented and added to the language, just as the > semantics of an old HTML document doesn't change just because we > invented the canvas tag. We're talking about _unintended_ content being injected in the pages. If browsers add some risky new feature (and I'm not saying canvas is that) then a site which doesn't use the feature shouldn't have to update their policy to stay opted-out. They never opted-in in the first place. Think "Principle of Least Surprise". >> From my >> perspective, the blocking occurs when something unexpected by the site was >> included in the page. In our model, the newer implementation, while >> potentially creating an inconsistency with the older version, has also >> potentially blocked an attack. > > You're extremely focused on load resources and missing the bigger picture. You did not address my point which was one example of how opting-in to features provides better security. >> Are you suggesting that a blocked resource is more likely to have come from >> a web developer who forgot to update the CSP when s/he added new content >> than it is to have been injected by an attacker? > > I'm not suggesting this at all. Nothing in my argument has to do with > probabilities. Okay, I'll pose the same question a different way: do you think it is more important to avoid false positives (allow harmful content through) than it is to avoid false negatives (block benign content) in the absence of an explicit policy? >> This seems like a >> dangerous assumption. All we are getting, in this case, is better >> consistency in behavior from CSP implementation-to-implementation, but not >> better security. > > Consistency between implementation is essential. Mitigating important > threats is also essential. Nether is more important than the other. I disagree. I don't see how consistency between implementation is as important as threat mitigation. Isn't the damage that can be done to a user via an exploited vulnerability worse than what would happen to them if the site rendered differently than another user with a different browser? >> From the perspective of websites, CSP modules are just one more thing that >> they have to keep track of in terms of which browsers support which modules. > > In the subtractive design, web developers don't need to care at all > which browsers support which modules. They can simply turn off the > features they're not using. They can only "turn off the features they're not using" in the browsers that support that module. The same goes for the opt-in method. My point was that they will have to keep track of modules that are supported in each browser if they want to keep a clear picture of their risk profile across all their users. > Browsers that understand those modules > will provide additional security. Browsers that don't understand > those modules will be blissfully ignorant. The same thing applies to the opt-in model. Browsers that don't understand some directive will skip over it, not restricting that type of content loading in any way. >>> Balancing against these pros, the con seem to be that we hope the >>> additive, opt-out syntax will prod web developers into realizing that >>> adding "script-src inline" to the tutorial code they copy-and-paste is >>> more dangerous than removing "block-xss". >> >> Those seem equivalent to me, so I'm not sure which model your example >> favors. > > If those seem equivalent, they why not adopt the less complex, more > extensible design? In this entire email, you haven't stated why we > should prefer the tightly coupled design / opt-out over the modular > opt-in design. I believe I have provided concrete examples that show that opt-in is a more secure model. If you really require that I go out and find a bunch of references for you to further illustrate that a whitelist is a better security paradigm than a blacklist, I can do that. >> I do want CSP to be easy to get right. I should do some homework and >> collect some stats on real world websites to support the following claim, >> but I still maintain that a HUGE number of sites will be able to benefit >> greatly from a minimal policy such as "allow 'self'". Even "allow *" would >> be a gigantic improvement in terms of blocking all the common XSS vectors. > > The "allow *" policy does not mitigate *any* Type-I or Type-II XSS > vulnerabilities. If you, an expert in this topic, does not understand > this fact, then I have little hope that web developers will be able to > understand how to use CSP, as currently designed, correctly. I did make a mistake and you were justified in bludgeoning me with it. However, what I should have said was "even "allow *" would block _some_ of the common XSS vectors". Your statement that "allow *" does not mitigate *any* type I or II XSS is wrong. A very common XSS pattern is attribute injection, where an attacker can't get angle brackets and full tags injected, but they can inject an event-handling attribute in some existing element. These vulnerabilities would be mitigated by "allow *". I apologize for the overstatement. I look forward to your response and hope we can find a way forward soon. Cheers, Brandon _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
