Re: CSRF Module (was Re: Comments on the Content Security Policy specification)

2009-10-28 Thread Gervase Markham
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

Re: CSRF Module (was Re: Comments on the Content Security Policy specification)

2009-10-28 Thread Gervase Markham
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

Re: CSRF Module (was Re: Comments on the Content Security Policy specification)

2009-10-27 Thread Adam Barth
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

Re: CSRF Module (was Re: Comments on the Content Security Policy specification)

2009-10-27 Thread Devdatta
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

Re: CSRF Module (was Re: Comments on the Content Security Policy specification)

2009-10-27 Thread Daniel Veditz
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

Re: CSRF Module (was Re: Comments on the Content Security Policy specification)

2009-10-27 Thread Adam Barth
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

Re: CSRF Module (was Re: Comments on the Content Security Policy specification)

2009-10-27 Thread Brandon Sterne
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

Re: CSRF Module (was Re: Comments on the Content Security Policy specification)

2009-10-26 Thread Daniel Veditz
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

Re: CSRF Module (was Re: Comments on the Content Security Policy specification)

2009-10-26 Thread Devdatta
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

Re: Comments on the Content Security Policy specification

2009-10-23 Thread Gervase Markham
On 23/10/09 01:50, Daniel Veditz wrote: blocking inline-script is key to stopping XSS. We added the ability to turn that bit of CSP off as an interim crutch for complex sites trying to convert, but if our proof-of-concept site has to rely on it we've clearly failed and will be setting a bad

Re: Comments on the Content Security Policy specification

2009-10-22 Thread Gervase Markham
On 21/10/09 17:25, Sid Stamm wrote: Additional Directives are not a problem either, unless they're mandatory for all policies (which is not the case ... yet). I'm still more in favor of extension via new directives than extension by modifying existing ones: this seems more obviously backward

Re: Comments on the Content Security Policy specification

2009-10-22 Thread Mike Ter Louw
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

CSRF Module (was Re: Comments on the Content Security Policy specification)

2009-10-22 Thread Adam Barth
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

Re: CSRF Module (was Re: Comments on the Content Security Policy specification)

2009-10-22 Thread Mike Ter Louw
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

Re: CSRF Module (was Re: Comments on the Content Security Policy specification)

2009-10-22 Thread Adam Barth
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

Re: CSRF Module (was Re: Comments on the Content Security Policy specification)

2009-10-22 Thread Mike Ter Louw
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).

Re: CSRF Module (was Re: Comments on the Content Security Policy specification)

2009-10-22 Thread Devdatta
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

Re: CSRF Module (was Re: Comments on the Content Security Policy specification)

2009-10-22 Thread Adam Barth
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

Re: CSRF Module (was Re: Comments on the Content Security Policy specification)

2009-10-22 Thread Mike Ter Louw
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

Re: CSRF Module (was Re: Comments on the Content Security Policy specification)

2009-10-22 Thread Mike Ter Louw
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),

Re: CSRF Module (was Re: Comments on the Content Security Policy specification)

2009-10-22 Thread Adam Barth
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

Re: CSRF Module (was Re: Comments on the Content Security Policy specification)

2009-10-22 Thread Brandon Sterne
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

Re: CSRF Module (was Re: Comments on the Content Security Policy specification)

2009-10-22 Thread Collin Jackson
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

Re: CSRF Module (was Re: Comments on the Content Security Policy specification)

2009-10-22 Thread Mike Ter Louw
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

Re: CSRF Module (was Re: Comments on the Content Security Policy specification)

2009-10-22 Thread Daniel Veditz
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

Re: CSRF Module (was Re: Comments on the Content Security Policy specification)

2009-10-22 Thread Adam Barth
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

Re: Comments on the Content Security Policy specification

2009-10-21 Thread Gervase Markham
On 20/10/09 21:20, Sid Stamm wrote: While I agree with your points enumerated above, we should be really careful about scope creep and stuffing new goals into an old idea. The original point of CSP was not to provide a global security infrastructure for web sites, but to provide content

Re: Comments on the Content Security Policy specification

2009-10-21 Thread Sid Stamm
On 10/21/09 2:49 AM, Gervase Markham wrote: I think we need to differentiate between added complexity in syntax and added complexity in implementation. If we design the syntax right, there is no need for additional CSP directives to make the syntax more complicated for those who neither

Re: Comments on the Content Security Policy specification

2009-10-20 Thread Collin Jackson
I put together a brief description of the history module proposal on the wiki: https://wiki.mozilla.org/Security/CSP/HistoryModule On Tue, Oct 20, 2009 at 10:03 AM, Collin Jackson mozi...@collinjackson.com wrote: If you want to make a module that prevents history sniffing completely against

Re: Comments on the Content Security Policy specification

2009-10-20 Thread Mike Ter Louw
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

Re: Comments on the Content Security Policy specification

2009-10-20 Thread Devdatta
class) can give people power to do surprising things (e.g. internal network ping sweeping, user history enumeration respectively). Isn't the ping sweeping threat already taken care of by CSP? No requests to internal networks will be honored as they won't be allowed by the policy. (although its

Re: Comments on the Content Security Policy specification

2009-10-20 Thread Adam Barth
On Tue, Oct 20, 2009 at 12:47 PM, Mike Ter Louw mter...@uic.edu wrote: 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

Re: Comments on the Content Security Policy specification

2009-10-20 Thread Sid Stamm
On 10/20/09 12:58 PM, Adam Barth wrote: I think one of the goals of CSP is to avoid having one-off HTTP headers for each threat we'd like to mitigate. Combining different directives into a single policy mechanism has advantages: 1) It's easier for web site operators to manage one policy.

Re: Comments on the Content Security Policy specification

2009-10-20 Thread Collin Jackson
On Tue, Oct 20, 2009 at 1:20 PM, Sid Stamm s...@mozilla.com wrote: While I agree with your points enumerated above, we should be really careful about scope creep and stuffing new goals into an old idea.  The original point of CSP was not to provide a global security infrastructure for web

Re: Comments on the Content Security Policy specification

2009-10-20 Thread Adam Barth
In the modular approach, this is not true. You simply send this header: X-Content-Security-Policy: safe-history The requirements to remove inline script, eval, etc aren't present because you haven't opted into the XSSModule. You can, of course, combine them using this sort of policy:

Re: Comments on the Content Security Policy specification

2009-10-20 Thread Adam Barth
On Tue, Oct 20, 2009 at 1:42 PM, Collin Jackson mozi...@collinjackson.com wrote: I think we're completely in agreement, except that I don't think making CSP modular is particularly hard. In fact, I think it makes the proposal much more approachable because vendors can implement just BaseModule

Re: Comments on the Content Security Policy specification

2009-10-20 Thread Devdatta
Hi Sorry, I didn't read your modular approach proposal before sending the email. Cheers Devdatta On Oct 20, 2:03 pm, Adam Barth abarth-mozi...@adambarth.com wrote: In the modular approach, this is not true.  You simply send this header: X-Content-Security-Policy: safe-history The

Re: Comments on the Content Security Policy specification

2009-10-20 Thread Lucas Adamski
I'm not sure that providing a modular approach for vendors to implemented pieces of CSP is really valuable to our intended audience (web developers). It will be hard enough for developers to keep track of which user agents support CSP, without requiring a matrix to understand which

Re: Comments on the Content Security Policy specification

2009-10-20 Thread Collin Jackson
Why do web developers need to keep track of which user agents support CSP? I thought CSP was a defense in depth. I really hope people don't use this as their only XSS defense. :) On Tue, Oct 20, 2009 at 2:25 PM, Lucas Adamski lu...@mozilla.com wrote: I'm not sure that providing a modular

Re: Comments on the Content Security Policy specification

2009-10-20 Thread Lucas Adamski
We should think ahead, not just a year or two but to the point that all current browsers will be EOL and (just like every other feature that is currently in HTML5) this will be widely adopted and reliable. Lucas. On Oct 20, 2009, at 2:30 PM, Collin Jackson wrote: Why do web developers

Re: Comments on the Content Security Policy specification

2009-10-20 Thread Collin Jackson
It seems to me that thinking ahead would tend to favor the modular approach, since we're unlikely to guess the most compelling use cases on the first try, and modules will provide a backwards-compatible means of evolving the spec to what web authors actually need. On Tue, Oct 20, 2009 at 2:49 PM,

Re: Comments on the Content Security Policy specification

2009-10-20 Thread Devdatta
I actually think the modular approach is better for the web developer as the policy is easier to write and understand. But I do share your concern, Atleast right now, it is pretty easy to say -- user agents that support XSSModule are protected against XSS and user agents that support history

Re: Comments on the Content Security Policy specification

2009-10-20 Thread Lucas Adamski
I've been a firm believer that CSP will evolve over time but that's an argument for versioning though, not modularity. We are as likely to have to modify existing behaviors as introduce whole new sets. It's also not a reason to split the existing functionality into modules. Lucas On Oct

Versioning vs. Modularity (was Re: Comments on the Content Security Policy specification)

2009-10-20 Thread Adam Barth
On Tue, Oct 20, 2009 at 3:21 PM, Lucas Adamski lu...@mozilla.com wrote: I've been a firm believer that CSP will evolve over time but that's an argument for versioning though, not modularity. We are as likely to have to modify existing behaviors as introduce whole new sets.  It's also not a

Re: Comments on the Content Security Policy specification

2009-10-20 Thread Lucas Adamski
I'm confident we can figure out how best to communicate CSP use cases to developers independent of implementation. What we should have are documentation modules that walk a web dev through specific goal-driven examples, for example. The problem with modules I see is they will complicate

Re: Versioning vs. Modularity (was Re: Comments on the Content Security Policy specification)

2009-10-20 Thread Lucas Adamski
I'm not a fan of it but it's unavoidable for a security mechanism. We already had bugs filed against CSP that would result in content impacting behavioral changes. Not to mention that even module-centric functionality would have to be revised to govern new APIs and new types of attacks

Re: Module granularity (Re: Comments on the Content Security Policy specification)

2009-10-20 Thread Lucas Adamski
The reporting infrastructure does seem pretty easy to modularize but it's also a bit exceptional as it doesn't drive any actual content behaviors. I'm going to have to chew on this some more but my primary concern remains that this approach could increase complexity and reduce reliability

Re: Comments on the Content Security Policy specification

2009-10-20 Thread Devdatta
On a related note, just to have one more example (and for my learning) , I went ahead and wrote a draft for ClickJackingModule. https://wiki.mozilla.org/Security/CSP/ClickJackingModule In general I like how short and simple each individual module is. Cheers Devdatta 2009/10/20 Lucas Adamski

ClickJackingModule (was Re: Comments on the Content Security Policy specification)

2009-10-20 Thread Adam Barth
Thanks Devdatta. One of the nice thing about separating the clickjacking concerns from the XSS concerns is that developers can deploy a policy like X-Content-Security-Policy: frame-ancestors self without having to make sure that all the setTimeout calls in their web app use function objects

Re: ClickJackingModule (was Re: Comments on the Content Security Policy specification)

2009-10-20 Thread Lucas Adamski
Note that the XSS mitigations can be opted out of, so we shouldn't assume that mitigating something specific like clickjacking requires XSS mitigations in the current proposal. Lucas. On Oct 20, 2009, at 6:50 PM, Adam Barth wrote: Thanks Devdatta. One of the nice thing about separating

Re: Comments on the Content Security Policy specification

2009-10-19 Thread Johnathan Nightingale
On 19-Oct-09, at 7:34 AM, Gervase Markham wrote: On 15/10/09 22:20, Brandon Sterne wrote: IOW, we need to decide if webpage defacement via injected style is in the treat model for CSP and, if so, then we need to do B. Is it just about defacement, or is it also about the fact that CSS can

Re: Comments on the Content Security Policy specification

2009-10-19 Thread Adam Barth
On Mon, Oct 19, 2009 at 6:43 AM, Johnathan Nightingale john...@mozilla.com wrote: Not as limited as you might like. Remember that even apparently non-dangerous constructs (e.g. background-image, the :visited pseudo class) can give people power to do surprising things (e.g. internal network ping

Re: Comments on the Content Security Policy specification

2009-10-15 Thread Brandon Sterne
On 07/30/2009 07:06 AM, Gervase Markham wrote: On 29/07/09 23:23, Ian Hickson wrote: * Combine style-src and font-src That makes sense. I agree. @font-face has to come from CSS which is already subject to style-src restrictions. I don't think there are any practical attacks we are

Re: Comments on the Content Security Policy specification

2009-09-03 Thread Gervase Markham
On 12/08/09 00:11, Ian Hickson wrote: I think in almost all cases, multiple headers will be a sign of an attack or error, not the sign of cooperation. OK. I think that's a fair challenge. Can someone come up with a plausible and specific scenario where multiple headers would be useful? The

Re: Comments on the Content Security Policy specification

2009-08-11 Thread Gervase Markham
On 10/08/09 19:50, Brandon Sterne wrote: Working examples will be forthcoming as soon as we have Firefox builds available which contain CSP. We shouldn't need to wait for working builds to try and work out the policies, should we? Although perhaps it would be a lot easier if you could test

Re: Comments on the Content Security Policy specification

2009-08-11 Thread Ian Hickson
On Thu, 30 Jul 2009, Gervase Markham wrote: On 29/07/09 23:23, Ian Hickson wrote: * Remove external policy files. I'm not sure how that's a significant simplification; the syntax is exactly the same just with an extra level of indirection, and if that makes things too complicated for

Re: Comments on the Content Security Policy specification

2009-08-10 Thread TO
On a related note (to Ian's initial message), I'd like to ask again to see some real-world policy examples. I suggested CNN last time, but if something like Twitter would be an easier place to start, maybe we could see that one? Or see the example for mozilla.org, maybe? Or even just some toy

Re: Comments on the Content Security Policy specification

2009-08-10 Thread Brandon Sterne
On 8/10/09 10:27 AM, TO wrote: I'd like to ask again to see some real-world policy examples. I suggested CNN last time, but if something like Twitter would be an easier place to start, maybe we could see that one? Or see the example for mozilla.org, maybe? Or even just some toy problems to

Re: Comments on the Content Security Policy specification

2009-08-10 Thread Sid Stamm
On 8/10/09 5:00 AM, Gervase Markham wrote: On 30/07/09 18:51, Daniel Veditz wrote: * Move inline and eval keywords from script-src to a separate directive, so that all the -src directives have the same syntax I've argued that too and I think we agreed, although I don't see that reflected in

Re: Comments on the Content Security Policy specification

2009-07-30 Thread Gervase Markham
On 29/07/09 23:23, Ian Hickson wrote: * Remove external policy files. I'm not sure how that's a significant simplification; the syntax is exactly the same just with an extra level of indirection, and if that makes things too complicated for you, don't use them. * Removemeta policies.

Re: Comments on the Content Security Policy specification

2009-07-17 Thread Jean-Marc Desperrier
Daniel Veditz wrote: CSP is designed so that mistakes of omission tend to break the site break. This won't introduce subtle bugs, rudimentary content testing will quickly reveal problems. But won't authors fail to understand how to solve the problem, and open everything wide ? From

Re: Comments on the Content Security Policy specification

2009-07-17 Thread Jean-Marc Desperrier
Daniel Veditz wrote: CSP is designed so that mistakes of omission tend to break the site break. This won't introduce subtle bugs, rudimentary content testing will quickly reveal problems. But won't authors fail to understand how to solve the problem, and open everything wide ? From

Re: Comments on the Content Security Policy specification

2009-07-17 Thread Jean-Marc Desperrier
Daniel Veditz wrote: CSP is designed so that mistakes of omission tend to break the site break. This won't introduce subtle bugs, rudimentary content testing will quickly reveal problems. But won't authors fail to understand how to solve the problem, and open everything wide ? From

Re: Comments on the Content Security Policy specification

2009-07-17 Thread Jean-Marc Desperrier
Bil Corry wrote: CSP is non-trivial; it takes a bit of work to configure it properly and requires on-going maintenance as the site evolves. It's not targeted to the uninformed author, it simply isn't possible to achieve that kind of coverage -- I suspect in the pool of all authors, the majority

Re: Comments on the Content Security Policy specification

2009-07-17 Thread Sid Stamm
On 7/17/09 8:40 AM, Bil Corry wrote: An external validation tool could help authors understand what their CSP rules are actually allowing/preventing (maybe something similar to validator.w3.org). To compliment it, another handy tool would be a browser plug-in that could help create CSP

Re: Comments on the Content Security Policy specification

2009-07-17 Thread Brandon Sterne
On 7/16/09 8:17 PM, Ian Hickson wrote: On Thu, 16 Jul 2009, Daniel Veditz wrote: Ian Hickson wrote: * The more complicated something is, the more mistakes people will make. We encourage people to use the simplest policy possible. The additional options are there for the edge cases. It

Re: Comments on the Content Security Policy specification

2009-07-17 Thread Daniel Veditz
Jean-Marc Desperrier wrote: In fact a solution could be that everytime the browser reject downloading a ressource due to CSP rules, it spits out a warning on the javascript console together with the minimal CSP authorization that would be required to obtain that ressource. This could help

Re: Comments on the Content Security Policy specification

2009-07-16 Thread Bil Corry
Ian Hickson wrote on 7/16/2009 5:51 AM: I think that this complexity, combined with the tendency for authors to rely on features they think are solvign their problems, would actually lead to authors writing policy files in what would externally appear to be a random fashion, changing them