Re: Comments on the Content Security Policy specification
Gervase Markham wrote: I think it would be good if we didn't have to invent a new header for each idea of ways to lock down content. I think it would be great if people could experiment with Content-Security-Policy: x-my-cool-idea, and see if it was useful before standardization. Any idea which is a policy for content security should be in scope for experimentation. I've added a CSRF straw-man: https://wiki.mozilla.org/Security/CSP/CSRFModule This page borrows liberally from XSSModule. Comments are welcome! 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)
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)
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)
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)
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: Comments on the Content Security Policy specification
Collin Jackson wrote: If you want to make a module that prevents history sniffing completely against specific sites and avoids assuming the user never interacts with a bad site, you could have a CSP module that allows a server to specify whether its history entries can be treated as visited by other origins. Sites concerned about user privacy would then have control over whether other sites could detect that they've been visited. A similar module could be used for cross-origin cache loads to address timing attacks. Collin Jackson wrote: I put together a brief description of the history module proposal on the wiki: https://wiki.mozilla.org/Security/CSP/HistoryModule The threat model of HistoryModule, as currently defined, seems to be precisely the threat model that would be addressed by a similar module implementing a per-origin cache partitioning scheme to defeat history timing attacks. If these are to be kept as separate modules, then perhaps the threat model should be more tightly scoped, and directive names should be specific to the features they enable? I like the idea of modularizing CSP. Mike ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Straw-main XSSModule for CSP
Adam Barth wrote: I've taken the liberty of sketching out a straw-man XSSModule for CSP on the Mozilla wiki: https://wiki.mozilla.org/Security/CSP/XSSModule I welcome your feedback, Adam Hi Adam, I'm not sure if hacking at the straw man should occur on the list or on the wiki. Please let me know if it should go to the wiki. Threat Model: We further assume the web developer wishes to prevent the attacker from achieving any of the following goals: * The attacker must not learn the contents of the target web site's cookies. A broader definition than cookie stealing that also covers integrity issues like defacement could be: * The attacker's sequence of injected bytes are interpreted as one or more script instructions and executed with the privileges of the (CSP-protected) document. If the purpose of the threat model is to scope out the protections afforded by the module, then the following may be more appropriate: * The attacker's sequence of injected bytes are interpreted as an inline script (i.e., script element without |src| attribute, script element attribute, javascript: URI, dynamic CSS, etc.) * The attacker's sequence of injected bytes are interpreted as a reference to external script, where the external script is located at a different origin to the document protected by CSP * The attacker's sequence of injected bytes are compiled as a result of executing an allowed script (e.g., via eval(), setTimeout(), setInterval(), or Function constructor) block-xss directive: The effects of this directive are given in a default-allow style, which could lead to gaps in protection. (Some possible gaps are commented on in the Open Issues section.) Could the effects of block-xss be specified as exceptions to a default-deny policy? Open Issues section: IE's CSS behaviors and expressions could fit in the same category as XBL bindings, as they are non-standard features that can be used as XSS vectors Mike ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy feedback
Gervase Markham wrote: Sid Stamm wrote: What worries me is that with no assurance that they're enforced, CSP policies won't be provided by web sites since it takes time (granted, not much of it) to compose them. It's likely that a profit-driven company might rather have their engineers spend time fuzzing or bug fixing than designing a good CSP string that may or may not ever be used. It really doesn't take long - it's not a complicated spec. I'm not sure we need to make it more attractive by promising what we can't deliver. One concern is the time and effort required to refactor existing code to use only external scripts (a non-trivial task). Development of new web code can take this restriction into account but still requires deliberate effort throughout the development cycle to maintain support for CSP. I think utilizing CSP will be a very conscious decision by web site operators, weighing the benefits CSP offers, the cost of implementing and maintaining CSP support, and the risks of not adding CSP to their web site. While it would be nice to have a low cost, effective, add-on layer of security, it seems the requirement of no inline script code adds significantly to the cost of CSP. Therefore site owners should be able to estimate the benefit CSP will give them by measuring the level of browser support among the site's visitors, so it can be weighed against the cost of CSP deployment. Is it correct that the rule against inline scripts is in effect for all CSP policies, even when script-src is not used? Mike ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: IE8 security features
Gervase Markham wrote: Robert O'Callahan wrote in mozilla.dev.planning: 3) Some kind of dynamic anti-XSS filter that monitors browser traffic and blocks stuff. Not many details about that yet. This latter is an interesting idea, but it sounds to me like a recipe for hard-to-understand breakage and bugs, particularly if ours works differently to theirs. I'd be interested in closer analysis of what proportion of attacks this might address, and whether we can immediately think of ways attackers could break it. Does anyone have more info, or comments on their approach? The doc is here: http://blogs.msdn.com/ie/archive/2008/07/02/ie8-security-part-iv-the-xss-filter.aspx In the MSDN blog comments, Giorgio Maone links to documentation for a similar feature of NoScript: http://noscript.net/features#xss Mike ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Looking for GSoC mentor to extension security project
Hi List, I'm going to submit an application for the Google Summer of Code program with the hopes of working with the Mozilla Foundation. Specifically, I would like to enhance Mozilla Firefox's extensible architecture to make it more secure against malicious code. I was wondering if there is someone on this list who would be qualified (and interested!) as a mentor for this project, or if an individual could be recommended. There is currently a paper in submission on the recent work I've done on this topic with my Ph.D. advisor and another graduate student. We have isolated some problem areas but have not had sufficient time and resources to address them all. The current work spans the Firefox Extension Manager, XUL Document loader, Spidermonkey, and more. I would like to extend the project to also incorporate parts of NSS and the Component Registrar. I am hopeful that the work can be completed in a way that would be acceptable for incorporation into the Firefox code base by working with Mozilla.org over the Summer. I'll be writing up a technical report on our initial work to accompany my application. Prior to that, please let me know if additional project details would be helpful with this inquiry. Sincerely, Mike Ter Louw Ph.D. Candidate, Computer Science University of Illinois at Chicago [EMAIL PROTECTED] ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
