Re: Opt-in versus opt-out (was Re: CSRF Module)
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 I don't think that is what Adam is arguing about. Writing protocols for the web is fundamentally different from that for other systems. A fundamental constraint (amongst others) which you should support is (random term) 'anarchic' extensibility. 'Anarchic' in the sense that we don't know what/how the system is going to be extended and we probably wont have a say in it. Designing under such constraints, he proposes a policy mechanism which involves blacklisting only. Current-CSP on the other hand seems to have started from 'white listing is the most secure way' and then gone on to develop a mechanism for the web. Whitelisting might be the most secure way but that doesn't necessarily equate with good for the web. If you can come up with a mechanism that under these web constraints is still white list only, you are most welcome. Don't get me wrong , I do agree with your approach. But the argument isn't as simple as whitelisting vs. blacklisting -- if you phrase it that way no security researcher is going to say 'blacklisting'. Cheers Devdatta ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Strawman CSP counter proposal
Instead of arguing abstractly about design, I've written up a (mostly!) complete spec for an alternative CSP design: https://wiki.mozilla.org/Security/CSP/Strawman I've purposely gone overboard on the directives, but most of these directives are based on real feature requests I've received from web developers. I don't actually think we should do all of them in the first iteration. I just wanted to give you a flavor of the kinds of things you could do with this sort of mechanism. Adam ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: CSRF Module (was Re: Comments on the Content Security Policy specification)
On 27/10/09 09:33, Adam Barth wrote: My technical argument is as follows. I think that CSP would be better off with a policy language where each directive was purely subtractive because that design would have a number of simplifying effects: CSP's precursor, Content Restrictions http://www.gerv.net/security/content-restrictions/ was designed to be purely subtractive, for many of the technical reasons you state. And I do continue to think that it's a better choice. Why write the spec in terms of restrictions rather than capabilities? Backwards-compatibility. Current user agents are fully capable. Any restrictions we can place on content to possibly mitigate XSS is therefore a bonus. Also, if it were in terms of capabilities, you might require UI if the capabilities the page wanted conflicted with the desires of the user. This is a UI-free specification, which is a feature. Gerv ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: CSRF Module (was Re: Comments on the Content Security Policy specification)
On 28/10/09 16:23, Gervase Markham wrote: On 27/10/09 09:33, Adam Barth wrote: My technical argument is as follows. I think that CSP would be better off with a policy language where each directive was purely subtractive because that design would have a number of simplifying effects: CSP's precursor, Content Restrictions http://www.gerv.net/security/content-restrictions/ was designed to be purely subtractive, for many of the technical reasons you state. And I do continue to think that it's a better choice. Having said that, it doesn't preclude the very presence of the header implying some restrictions. It just means that if the presence of the header implies some restrictions, you shouldn't be able to remove those restrictions by adding tokens to the header. Gerv ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Opt-in versus opt-out (was Re: CSRF Module)
X-IMHO-Hat: On Purely regarding opt-in vs opt-out: One significant advantage of the opt-out (of protections) approach rather than the opt-in approach is that it generally maps well to common web developer workflows. The opt-out model generally requires web developers to model their expected application behavior (which API's they use, that external advertisers they import, which image servers they use, plugins they allow, etc.) This only requires knowledge of their expected site behavior, but little security knowledge. It also has advantages in testing insofar that the developer only needs to add directives until their website works properly, which is the type of positive testing web developers are generally quite good at. One weakness with opt-in is that it requires the developer to understand what threats they want to mitigate and implement those restrictions correctly. This is much harder for web developers to do from my experience, as it requires significant security knowledge; the complexity of the policy will always have to be somewhat proportional to the complexity of the site so I don't think we can design this problem away. Now I completely agree that given a flexible enough model (opt-in or opt-out) what you would see develop is common policies being developed into patterns, so the developer could hopefully find the right set of patterns to help them implement their policies, given the right resources and some basic security knowledge. However, the issue is that the developer still can't determine if those policies are the strongest policies from a security standpoint, since its a negative testing problem. So the model I would recommend for web developers that want optimal security would be to enable all of the protections, then loosen them individually until the site works properly. Which is really no different from the opt- out model. This is a general best practice for securing any environment (ask anyone in IT). So it seems regardless of opt-in vs opt-out, the optimal approach for web developers is to model what their expected environment is and enable only that functionality. Both models suffer from the same flaw of course: the developer could enable things that allow their site to operate properly but also leave them wide open to attack. I have to say as an aside, there has been a lot of argument about which model is more extensible or less complex. Frankly that all seems rather subjective to me and not super productive, so I'd probably be more effective if nobody assumed their model is inherently more or less complex as we are not getting any closer to consensus there. If there are specific areas where we can actually compare complexity, then please lets just focus on those. So far I haven't seen a single concrete example. From https://wiki.mozilla.org/Security/CSP/Strawman (thank you for posting that, btw), they seem largely equivalent in terms of nature and number of directives. Thanks, Lucas. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
