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: CSRF Module (was Re: Comments on the Content Security Policy specification)
On Mon, Oct 26, 2009 at 6:11 PM, Daniel Veditz dved...@mozilla.com wrote: They have already opted in by adding the CSP header. Once they've opted-in to our web-as-we-wish-it-were they have to opt-out of the restrictions that are too onerous for their site. I understand the seductive power of secure-by-default here. It's important to understand what we're giving up in terms of complexity and extensibility. We feel extraordinarily strongly that sites should have to explicitly say they want to run inline-script, like signing a waiver that you're going against medical advice. The only thing that is likely to deter us is releasing a test implementation and then crashing and burning while trying to implement a reasonable test site like AMO or MDC or the experiences of other web developers doing the same. This statement basically forecloses further discussion because it does not advance a technical argument that I can respond to. In this forum, you are the king and I am but a guest. 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: 1) Forward and backward compatibility. As long as sites did not use the features blocked by their CSP directives, their sites would function correctly in partial / future implementations of CSP. 2) Modularity. We would be free to group the directives into whatever modules we liked because there would be no technical interdependence. 3) Trivial Combination. Instead of the current elaborate algorithm for combining policies, we could simply concatenate the directives. An attacker who could inject a Content-Security-Policy header could then only further reduce his/her privileges. 4) Syntactic Simplicity. Instead of two combination operators, ; for union and , for intersection, we could simply use , and match standard HTTP header syntax. 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. 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)
Hi There are two threads running in parallel here: 1) Should blocking XSS be default behaviour of adding a X-Content-Security-Policy? (instead of the straw man proposal where a additional 'block-xss' would be required ) 2) Should the result of blocking XSS also cause eval and inline scripts to be disabled? If 1 is the case, then blocking eval and inline scripts by default is imho unacceptable. The reasons are the same as Adam succinctly pointed out in his ' Forward and backward compatibility ' bullet in the previous mail. But if to enable XSS protection, the user types in block-xss, then I think Brandon argument makes sense. block-xss should block XSS , which requires us to disable eval and inline scripts. But if for compatibility the user wants to continue supporting them , he should explicity add support for them with say 'allow-eval'. With a block-eval directive, the correct policy would always be 'block-xss block-eval' which doesn't make sense to me if we are hoping that eval support would just be a stop gap while the web admins figure out how to get by without it. Regards Devdatta 2009/10/27 Adam Barth abarth-mozi...@adambarth.com: On Mon, Oct 26, 2009 at 6:11 PM, Daniel Veditz dved...@mozilla.com wrote: They have already opted in by adding the CSP header. Once they've opted-in to our web-as-we-wish-it-were they have to opt-out of the restrictions that are too onerous for their site. I understand the seductive power of secure-by-default here. It's important to understand what we're giving up in terms of complexity and extensibility. We feel extraordinarily strongly that sites should have to explicitly say they want to run inline-script, like signing a waiver that you're going against medical advice. The only thing that is likely to deter us is releasing a test implementation and then crashing and burning while trying to implement a reasonable test site like AMO or MDC or the experiences of other web developers doing the same. This statement basically forecloses further discussion because it does not advance a technical argument that I can respond to. In this forum, you are the king and I am but a guest. 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: 1) Forward and backward compatibility. As long as sites did not use the features blocked by their CSP directives, their sites would function correctly in partial / future implementations of CSP. 2) Modularity. We would be free to group the directives into whatever modules we liked because there would be no technical interdependence. 3) Trivial Combination. Instead of the current elaborate algorithm for combining policies, we could simply concatenate the directives. An attacker who could inject a Content-Security-Policy header could then only further reduce his/her privileges. 4) Syntactic Simplicity. Instead of two combination operators, ; for union and , for intersection, we could simply use , and match standard HTTP header syntax. 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. Adam ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security ___ 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 10/27/09 2:33 AM, Adam Barth wrote: I understand the seductive power of secure-by-default here. If only she loved me back. This statement basically forecloses further discussion because it does not advance a technical argument that I can respond to. In this forum, you are the king and I am but a guest. I don't think we're having a technical argument, and we're not getting the feedback we need to break the impasse in this limited forum. Either syntax can be made to express the same set of current restrictions. You're arguing for extensible syntax, and I'm arguing for what will best encourage the most web authors to do the right thing. An argument about whether your syntax is or is not more extensible can at least be made on technical merits, but what I really want is feedback from potential web app authors about which approach is more intuitive and useful to them. Those folks aren't here, and I don't know how to reach them. At a technical level your approach appears to be a blacklist. If I'm understanding you correctly, if there's an empty CSP header then there's no restriction whatsoever on the page. In our version it'd be a locked-down page with a default inability to load source from anywhere. If the web author has left something out they will know because the page will not work. I'd rather have that than a web author thinking they're safe when CSP isn't actually turned on for their page. The bottom line, though, is I'm in favor of anything that gets more web sites and more browsers to support the concept. -Dan ___ 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 Tue, Oct 27, 2009 at 12:39 PM, Daniel Veditz dved...@mozilla.com wrote: I don't think we're having a technical argument, and we're not getting the feedback we need to break the impasse in this limited forum. I agree that we're not making progress in this discussion. At a high level, the approach of letting sites to restrict the privileges of their own content is a rich space for security mechanisms. My opinion is that the current CSP design is overly complex for the use cases it supports and insufficiently flexible as a platform for addressing future use cases. If I find the time, I'll send along a full design that tries to improve these aspects along the lines I've suggested in the foregoing discussion. 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 10/27/2009 02:33 AM, 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: I couldn't find a comment that summarizes the model you are proposing so I'll try to recreate your position from memory of our last phone conversation. Please correct me where I'm wrong. I believe you advocate a model where a site specifies the directives it knows/cares about, and everything else is allowed. This model would make the default allow directive unnecessary. The main idea is to allow sites to restrict the things it knows about and not have to worry about inadvertently blocking things it doesn't consider a risk. My main objection to this approach is that it turns the whitelist approach we started with into a hybrid whitelist/blacklist. 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. Under your proposal, this site needs to explicitly opt-out of every directive, including any new directives that get added in the future. 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. 1) Forward and backward compatibility. As long as sites did not use the features blocked by their CSP directives, their sites would function correctly in partial / future implementations of CSP. 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. 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. 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? 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. 2) Modularity. We would be free to group the directives into whatever modules we liked because there would be no technical interdependence. I actually don't see how opt-in vs. opt-out has any bearing at all on module interdependence. Maybe you can provide an example? Let's also not forget that CSP modularity really only helps browser vendors. 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. I support the idea of making it easier for other browser vendors to implement CSP piecemeal, but our primary motivation should remain making the lives of websites and their users better. 3) Trivial Combination. Instead of the current elaborate algorithm for combining policies, we could simply concatenate the directives. An attacker who could inject a Content-Security-Policy header could then only further reduce his/her privileges. In the case of an injected header, this is already the case now. We intersect both policy sets, resulting in a combined policy more restrictive than either of the two separate policies. If we are talking about an attacker who can inject an additional directive into an existing CSP header then, yes, the attacker could relax the policy intended to be set by the site. I'm not sure how much I care about this case. 4) Syntactic Simplicity. Instead of two combination operators, ; for union and , for intersection, we could simply use , and match standard HTTP header syntax. Okay, sure. 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. In general, I'm slightly skeptical of the view that we need to base our design around the fact that admins will copy-paste from tutorials. Sure, this will happen in practice, but what is the probability that such a site is a high value target for an attacker, and by extension how important is it that such a site gets CSP right? Remember, a site cannot make their security profile any worse with CSP than without it. 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
Re: CSRF Module (was Re: Comments on the Content Security Policy specification)
On 10/22/09 6:09 PM, Adam Barth wrote: I agree, but if you think sites should be explicit, doesn't that mean they should explicitly opt-in to changing the normal (i.e., non-CSP) behavior? They have already opted in by adding the CSP header. Once they've opted-in to our web-as-we-wish-it-were they have to opt-out of the restrictions that are too onerous for their site. It seems very reasonable to mitigate history stealing and ClickJacking without using CSP to mitigate XSS. It seems reasonable to mitigate both of those without using CSP at all. History stealing is going to come from attacker.com where they aren't going to add headers anyway. The proposed CSP frame-ancestors could just as easily go into an extended X-Frame-Options (and be a better fit). And it's really only a partial clickjacking defense anyway so maybe that aspect should go into whatever defense feature prevents the rest of clickjacking. NoScript's ClearClick seems to do a pretty good job (after a rough start) and gets to the heart of the issue without requiring site changes. I think we're all agreed on this point. Our current disagreements appear to be: 1) Whether frame-src should be in the resources module or in the same module as frame-ancestor. 2) Whether sites should have to opt-in or opt-out to disabling inline script and/or eval-like APIs. I don't think this is the right venue for deciding the latter, the audience here just doesn't have enough of the right people. We feel extraordinarily strongly that sites should have to explicitly say they want to run inline-script, like signing a waiver that you're going against medical advice. The only thing that is likely to deter us is releasing a test implementation and then crashing and burning while trying to implement a reasonable test site like AMO or MDC or the experiences of other web developers doing the same. The eval stuff I feel a lot less strongly about the default, but feel there's value in consistency of having site authors loosen restrictions rather than have some tighten and some loosen. -Dan ___ 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)
It seems reasonable to mitigate both of those without using CSP at all. +1. But the current spec was trying to address them. For e.g all the img-src, frame-src , frame-ancestor, font-src, style-src isn't really needed for preventing XSS (afaik). My view is that there is not problem with including them. The word 'content-security-policy' is very generic. If it is only going to apply for XSS then you should rename it to something more specific. clickjacking. NoScript's ClearClick seems to do a pretty good job (after a rough start) and gets to the heart of the issue without requiring site changes. Agreed. I am nott sure if it would be easy for browser vendors to actually implement something like ClearClick. Ideally ClearClick is the correct way to solve the threat (over frame ancestors). Cheers Devdatta ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
CSRF Module (was Re: Comments on the Content Security Policy specification)
On Thu, Oct 22, 2009 at 8:58 AM, Mike Ter Louw mter...@uic.edu wrote: I've added a CSRF straw-man: https://wiki.mozilla.org/Security/CSP/CSRFModule This page borrows liberally from XSSModule. Comments are welcome! Two comments: 1) The attacker goal is very syntactic. It would be better to explain what the attacker is trying to achieve instead of how we imagine the attack taking place. 2) It seems like an attacker can easily circumvent this module by submitting a form to attacker.com and then generating the forged request (which will be sent with cookies because attacker.com doesn't enables the anti-csrf directive). 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)
Adam Barth wrote: 2) It seems like an attacker can easily circumvent this module by submitting a form to attacker.com and then generating the forged request (which will be sent with cookies because attacker.com doesn't enables the anti-csrf directive). I agree. It seems anti-csrf (as currently defined) would be most beneficial for defending against CSRF attacks that don't require any user action beyond simply viewing the page (e.g., img src=attack). Form actions would perhaps require some additional constraints, such as only allowing submission to |self| or other whitelisted URIs. Link activation is harder, because (I would assume) most websites want to allow links to different-origin URIs. And as you stated, not sending cookies here doesn't help because the link could go to attacker.com, and the page can contain an image based CSRF (thus the threshold for successful attack is still 1 click). Thanks for the feedback, Mike ___ 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 Thu, Oct 22, 2009 at 9:52 AM, Mike Ter Louw mter...@uic.edu wrote: I agree. It seems anti-csrf (as currently defined) would be most beneficial for defending against CSRF attacks that don't require any user action beyond simply viewing the page (e.g., img src=attack). Maybe we should focus the module on this threat more specifically. My understanding is that this is a big source of pain for folks who operate forums, especially for user-supplied images that point back to the forum itself. What if the directive was something like cookieless-images and affected all images, regardless of where they were loaded from? 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)
Adam Barth wrote: On Thu, Oct 22, 2009 at 9:52 AM, Mike Ter Louw mter...@uic.edu wrote: I agree. It seems anti-csrf (as currently defined) would be most beneficial for defending against CSRF attacks that don't require any user action beyond simply viewing the page (e.g., img src=attack). Maybe we should focus the module on this threat more specifically. My understanding is that this is a big source of pain for folks who operate forums, especially for user-supplied images that point back to the forum itself. What if the directive was something like cookieless-images and affected all images, regardless of where they were loaded from? I think this is a good start, and should be an option for sites that don't want CSP to provide any other CSRF restrictions. I've added an additional directive to the wiki, but it needs further definition. Mike ___ 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)
Maybe we should focus the module on this threat more specifically. My understanding is that this is a big source of pain for folks who operate forums, especially for user-supplied images that point back to the forum itself. What if the directive was something like cookieless-images and affected all images, regardless of where they were loaded from? requiring it to implement this policy regardless of the running script context would require the UA to maintain a cache of policies for each site the user has visited. This is against the requirements of the base module. And I for one am against any such type of caching requirement in the UA. cheers devdatta 2009/10/22 Adam Barth abarth-mozi...@adambarth.com: On Thu, Oct 22, 2009 at 9:52 AM, Mike Ter Louw mter...@uic.edu wrote: I agree. It seems anti-csrf (as currently defined) would be most beneficial for defending against CSRF attacks that don't require any user action beyond simply viewing the page (e.g., img src=attack). Maybe we should focus the module on this threat more specifically. My understanding is that this is a big source of pain for folks who operate forums, especially for user-supplied images that point back to the forum itself. What if the directive was something like cookieless-images and affected all images, regardless of where they were loaded from? Adam ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security ___ 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 Thu, Oct 22, 2009 at 10:15 AM, Mike Ter Louw mter...@uic.edu wrote: I think this is a good start, and should be an option for sites that don't want CSP to provide any other CSRF restrictions. I've added an additional directive to the wiki, but it needs further definition. I think it might be better to focus this module on the forum poster threat model. Instead of assuming the attacker can inject arbitrary content, we should limit the attacker to injecting content that is allowed by popular form sites (e.g., bbcode). At a first guess, I would limit the attacker to text, hyperlinks, and images. (And maybe bold / italics, if that matters.) On Thu, Oct 22, 2009 at 10:16 AM, Devdatta dev.akh...@gmail.com wrote: I don't understand. In each of the cases above, the attacker site will not enable the directives and img requests or form requests from his page will cause a CSRF to occur. We might decide to concern ourselves only with zero click attacks. Meaning that once the user has clicked on the attacker's content, all bets are off. If we imagine a 1% click-through rate, they we've mitigated 99% of the problem. On Thu, Oct 22, 2009 at 10:19 AM, Devdatta dev.akh...@gmail.com wrote: requiring it to implement this policy regardless of the running script context would require the UA to maintain a cache of policies for each site the user has visited. This is against the requirements of the base module. And I for one am against any such type of caching requirement in the UA. I agree that directives should affect only the current page. On Thu, Oct 22, 2009 at 10:31 AM, Mike Ter Louw mter...@uic.edu wrote: For image CSRF, some protection would be required against redirection. Either redirection must be disallowed, or anti-csrf needs to be enforced for all redirections until the resource is located. But I'm not sure if the latter is going to work if CSP policies are not composeable, and any of the redirections or the image itself defines a CSP policy. I agree that cookieless-images should affect all redirects involved in loading the image. Form requests to attacker.com would presumably be blocked, as attacker.com isn't in |self| nor the whitelist. So the attacker won't be able to direct the user to a page without anti-csrf protection using forms. But again this requires some enforcement of the whitelist during any redirects. I think we should assume that the attacker cannot inject form elements because this is uncommon in forum web sites. 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)
Adam Barth wrote: I think it might be better to focus this module on the forum poster threat model. Instead of assuming the attacker can inject arbitrary content, we should limit the attacker to injecting content that is allowed by popular form sites (e.g., bbcode). At a first guess, I would limit the attacker to text, hyperlinks, and images. (And maybe bold / italics, if that matters.) There should be room for each directive to address slightly different threat scenarios. For the forum threat you've described, the attack mechanics (i.e., CSRF) and basic remediation strategy (disallow sending cookies) are common to other threats the module aims to defend against. Additionally, cookieless-images is complementary to anti-csrf because it defines an additional constraint to images loaded from |self|. So perhaps the module needs to be better positioned and each directive better motivated. I think we should assume that the attacker cannot inject form elements because this is uncommon in forum web sites. That is fine for motivating cookieless-images, but this assumption could prove inadequate for other scenarios where the threat exists. It may be OK to remove the language governing form actions from CSRFModule if the issue is further deferred to another module (as does [1]), where this (currently hypothetical) module entirely blocks form submission if the action URI is not in a whitelist of trusted origins. (That would target the form-based password theft threat, as well as the CSRF threat.) There is a usability issue here: is it more usable (w.r.t. the web developer) to: (1) support a declaration of anti-csrf and enable the widest default set of protections that could be offered against CSRF (without being too strict as to break the most common use cases), but possibly having multiple modules specifying (complementary) form policies, or (2) group all form-related policies in a single module, even if the policies address fundamentally different attacks? In this case, this boils down to: should CSP directives be threat-centric or content-type-centric? Alternatively, this may be an example of CSP being too granular. Mike [1] https://wiki.mozilla.org/Security/CSP/XSSModule#Open_Issues ___ 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)
Mike Ter Louw wrote: There is a usability issue here: is it more usable (w.r.t. the web developer) to: (1) support a declaration of anti-csrf and enable the widest default set of protections that could be offered against CSRF (without being too strict as to break the most common use cases), but possibly having multiple modules specifying (complementary) form policies, or (2) group all form-related policies in a single module, even if the policies address fundamentally different attacks? Is it acceptable (not too strict) to block all form submission to non-self and non-whitelisted action URIs when the anti-csrf directive is given? If so, then the above usability issue may be moot: we can have anti-csrf imply an as-yet-undefined directive that blocks form submission. Mike ___ 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 Thu, Oct 22, 2009 at 12:36 PM, Mike Ter Louw mter...@uic.edu wrote: In this case, this boils down to: should CSP directives be threat-centric or content-type-centric? Alternatively, this may be an example of CSP being too granular. I suspect we'll need to experiment with different approaches before we have a good idea how to answer this question. In intuition tells me that we'd be better off with a threat-centric design, but it's hard to know ahead of time. On Thu, Oct 22, 2009 at 12:53 PM, Mike Ter Louw mter...@uic.edu wrote: Is it acceptable (not too strict) to block all form submission to non-self and non-whitelisted action URIs when the anti-csrf directive is given? If so, then the above usability issue may be moot: we can have anti-csrf imply an as-yet-undefined directive that blocks form submission. Instead of bundling everything together into anti-csrf, we might be better off with a directive to control where you can submit forms, e.g., form-action, but we seem to be getting far afield of the problem you're trying to solve. At a high level, I'm glad that you took the time to add your ideas to the wiki, and I hope that other folks will do the same. My personal opinion is that the current design has room for improvement, particularly around clarifying precisely what problem the module is trying to solve, but my opinion is just one among many. I'd like to encourage more people to contribute their ideas in the form of experimental modules, and hopefully the best ideas will rise to the top. 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)
I'd like to take a quick step back before we proceed further with the modularization discussion. I think it is fine to split CSP into modules, but with the following caveats: 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). 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 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. The script-src directive under the current model serves this function perfectly and doesn't need to be modified. (We can discuss how plugin content and CSS, which can be vectors for script, should be governed by this core XSS module.) As a straw man, the optional modules could be: * content loading (e.g. img-src, media-src, etc.) * framing (e.g. frame-src, frame-ancestors) * form action restriction * reporting (e.g. report-uri) * others? 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. Thoughts? -Brandon On 10/22/2009 09:37 AM, Adam Barth wrote: On Thu, Oct 22, 2009 at 8:58 AM, Mike Ter Louwmter...@uic.edu wrote: I've added a CSRF straw-man: https://wiki.mozilla.org/Security/CSP/CSRFModule This page borrows liberally from XSSModule. Comments are welcome! Two comments: 1) The attacker goal is very syntactic. It would be better to explain what the attacker is trying to achieve instead of how we imagine the attack taking place. 2) It seems like an attacker can easily circumvent this module by submitting a form to attacker.com and then generating the forged request (which will be sent with cookies because attacker.com doesn't enables the anti-csrf directive). 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 Thu, Oct 22, 2009 at 2:22 PM, Brandon Sterne bste...@mozilla.com 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. 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 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. 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'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. ___ 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)
Brandon Sterne wrote: I'd like to take a quick step back before we proceed further with the modularization discussion. I think it is fine to split CSP into modules, but with the following caveats: 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). Part of the value of the threat-centric module approach is it facilitates analysis of the defensive efficacy of CSP directives. This can point us to additional policies that are needed for more complete coverage, and reveal policies that are superfluous (I'm not saying any existing proposed policy is useless) and browser vendors need not implement. However, as Lucas rightly pointed out, the correctness of this analysis is dependent on our awareness and understanding of threats. If browser implementers are to pick and choose among CSP policies to support (besides XSS related ones, we agree), there should ideally be some reference that indicates the combined set of policies that are needed to mitigate each threat. This can aid browser implementers in deciding which policies to implement. For instance, if some browser vendor wants to support CSP protection against CSRF attacks, the vendor should know that it's of limited use to only strip cookies from form submissions; form action URIs must also be constrained to a set of trusted origins. Perhaps the spec can have an appendix recommending sets of directives for several significant threats, based on some thorough analysis of each threat, citing known capabilities and limitations of each set. This can benefit the spec writers, browser implementors and web developers. Mike ___ 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 10/22/09 10:31 AM, Mike Ter Louw wrote: Any ideas for how best to address the redirect problem? In the existing parts of CSP the restrictions apply to redirects. That is, if you only allow images from foo.com then try to load an image from a redirector on foo.com it will fail if the redirection is to some other site. (This has turned out to be an annoying part of CSP to implement as redirects happen deep in the network library far from the places that have the context to enforce this rule) Likewise your anti-csrf rules should propagate through redirects for consistency. ___ 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 Thu, Oct 22, 2009 at 5:22 PM, Brandon Sterne bste...@mozilla.com wrote: 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. I don't think this argument makes sense. When people complain about history stealing, e.g. on https://bugzilla.mozilla.org/show_bug.cgi?id=14, they're not worried about the case when their site has XSS. They're worried about a much weaker attacker who simply operates a web site. Why, though, would we ever want to change from an opt-in to an opt-out model? I don't think we'll want to change in the future. We should pick the better design now and stick with it (whichever design we decide is better). 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 agree, but if you think sites should be explicit, doesn't that mean they should explicitly opt-in to changing the normal (i.e., non-CSP) behavior? 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. I don't understand. There is no advertisement mechanism in CSP. Do you mean in the press? What's actually going to happen is that thought leaders will write blog posts with sample code and non-experts will copy/paste it into their web sites. Experts (e.g., PayPal) will read the spec and test various implementations. As for the press, I doubt anything we write in the spec will have much impact on how the press spins the story. Personally, I don't care about what the press says. We should design the best mechanism on a technical level. 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). It seems very reasonable to mitigate history stealing and ClickJacking without using CSP to mitigate XSS. As a web developer, I can't do anything about history stealing myself. I need help from the browser. On the the other hand, I can do something about XSS myself. 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. I think we're all agreed on this point. Our current disagreements appear to be: 1) Whether frame-src should be in the resources module or in the same module as frame-ancestor. 2) Whether sites should have to opt-in or opt-out to disabling inline script and/or eval-like APIs. I have a few more minor points, but we can get to those after we settle the above two. I think the way forward is for me (or someone else if they're interested) to write up our current thinking on the wiki. Adam ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
