Re: Comments on the Content Security Policy specification
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 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. On Tue, Oct 20, 2009 at 6:26 AM, Johnathan Nightingale john...@mozilla.com wrote: On 19-Oct-09, at 5:39 PM, Adam Barth wrote: 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 sweeping, user history enumeration respectively). I'm not arguing for or against providing the ability to block-inline-css, but keep in mind that an attacker can do all those things as soon as you visit attacker.com. Yeah, I think you're absolutely right that CSP is primarily about preventing attackers from exploiting your browser's trust relationship with victim.com, and the examples I offered are (for lack of a better term), victim-agnostic. They don't steal victim.com credentials or cause unwanted changes to, or transactions with, your victim.com presence. I do think, though, that a helpful secondary effect of CSP is that it reduces attackers' ability to amplify the effect of their attacks. You're right that it doesn't take much to get users to click on a link, but I think it is nevertheless the case that a good history enumerator or ping sweep which happens in the background while you're reading a NYTimes article will have a substantially higher success rate than a link in the comment section that says Click here for free goodies. Basically by definition, link-clickers are a subset of your total prospective victim pool. I think this is more specifically what makes me feel like there's still value to locking down all inline styling, or at least providing that facility, but I appreciate you forcing me to refine my thinking a little more. In the past, I've found it helpful to simply assume the user is always visiting attacker.com in some background tab. After all, Firefox is supposed to let you view untrusted web sites securely. Yes, absolutely so. We should continue to try to bend smarts towards fixing :visited and other nasty sleights-of-hand. But the one course of work doesn't preclude the other (and I don't think you were saying that it did). Johnathan --- Johnathan Nightingale Human Shield john...@mozilla.com ___ 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: 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: Comments on the Content Security Policy specification
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 not a threat present in the threat model for CSP ) Regarding , History enumeration -- I don't see why it should be part of CSP. A separate header - X-Safe-History can be used. Cheers Devdatta On Oct 19, 6:43 am, Johnathan Nightingale john...@mozilla.com wrote: 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 bring in behaviours etc? If it's about defacement, then there's no set of non-dangerous stylesheet constructs, and you can ignore my C. I think that, without executing JS code support, the successful attacks you could mount using CSS are limited. I guess you might put a notice on the bank website: Urgent! Call this number and give them all your personal info!... 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 sweeping, user history enumeration respectively). J --- Johnathan Nightingale Human Shield john...@mozilla.com ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Comments on the Content Security Policy specification
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 attacks. Good point. I've added cache timing as an open issue at the bottom of the HistoryModule wiki page. 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? It's somewhat unclear when to break things into separate modules, but having one module per threat seems to make sense. The visited link issue and the cache timing issue seem related enough (i.e., both about history stealing) to be in the same module. Adam ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Comments on the Content Security Policy specification
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. 2) The directives can share common infrastructure, like the reporting facilities. 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 restrictions and help stop XSS (mostly content restrictions). Rolling all sorts of extra threats like history sniffing into CSP will make it huge and complex, and for not what was initially desired. (A complex CSP isn't so bad if it were modular, but I don't think 'wide-reaching' was the original aim for CSP). Brandon, Gerv, step in and correct me if I'm wrong -- you were working on this long before me -- but I want to be really careful if we're going to start changing the goals of this project. If we want to come up with something extensible and wide-reaching, we should probably step back and seriously overhaul the design. -Sid ___ 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: Straw-main XSSModule for CSP
On Tue, Oct 20, 2009 at 1:26 PM, Mike Ter Louw mter...@uic.edu wrote: 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. I've be inclined to discuss feedback on the mailing list where others can see and comment most easily. 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. I tried to tighten down the attacker's goals to keep a narrow focus for the module. Running script with the page's privileges seems more like a means to an end rather than a goal unto itself. Although you could argue that stealing the cookie is also just a means to a different end. Either is probably fine, but I'm inclined to leave it as is for now. 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) These are too syntactic for an attacker goal. They pre-suppose a particular solution. 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? This is a good point. I wrote this as a series of MUST NOT requirements to make it easy to implement and test. We should do a better job of explaining the why behind the requirements. If we've missed anything, we should add more requirements to make sure each implementation behaves correctly. Maybe we should add a catch-all MUST NOT requirement that covers anything we've forgotten? 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 I've added this to the list of open issues. The catch-all MUST NOT might be sufficient to get these. We can of course mention them in a non-normative note to remind implementors. Thanks! Adam ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Comments on the Content Security Policy specification
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: X-Content-Security-Policy: safe-history, block-xss but you certainly don't have to. Adam On Tue, Oct 20, 2009 at 1:59 PM, Devdatta dev.akh...@gmail.com wrote: The history enumeration threat is a simple threat with a simple solution. Opting into Safe History protection shouldn't require me to do all the work of opting into CSP. In addition, I don't see any infrastructure that is needed by this feature that is in common with CSP. Lets say I am a website adminstrator, and I am concerned about this particular threat . Opting into CSP involves a lot of work - understanding the spec, noting down all the domains that interact everywhere on my site, removing inline scripts and evals and javascript URLs to corrected code etc. etc. My fear is that this will make admins write policies that are too lenient (say with allow-eval) , just to get the safe history feature. Cheers Devdatta 2009/10/20 Adam Barth abarth-mozi...@adambarth.com: On Tue, Oct 20, 2009 at 12:50 PM, Devdatta dev.akh...@gmail.com wrote: Regarding , History enumeration -- I don't see why it should be part of CSP. A separate header - X-Safe-History can be used. 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. 2) The directives can share common infrastructure, like the reporting facilities. Adam ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Comments on the Content Security Policy specification
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 (the CSP header syntax) and other modules they like such as XSSModule without feeling like they have to implement the ones they think aren't interesting. And they can experiment with their own modules without feeling like they're breaking the spec. I've factored the BaseModule out of the XSSModule, so it's clear that you could implement the HistoryModule without the XSSModule. I'd be happy to take a crack at breaking up the main CSP spec into modules on the wiki if you'd like to see what that would look like. I don't think it would be that hard. Adam ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Comments on the Content Security Policy specification
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 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: X-Content-Security-Policy: safe-history, block-xss but you certainly don't have to. Adam On Tue, Oct 20, 2009 at 1:59 PM, Devdatta dev.akh...@gmail.com wrote: The history enumeration threat is a simple threat with a simple solution. Opting into Safe History protection shouldn't require me to do all the work of opting into CSP. In addition, I don't see any infrastructure that is needed by this feature that is in common with CSP. Lets say I am a website adminstrator, and I am concerned about this particular threat . Opting into CSP involves a lot of work - understanding the spec, noting down all the domains that interact everywhere on my site, removing inline scripts and evals and javascript URLs to corrected code etc. etc. My fear is that this will make admins write policies that are too lenient (say with allow-eval) , just to get the safe history feature. Cheers Devdatta 2009/10/20 Adam Barth abarth-mozi...@adambarth.com: On Tue, Oct 20, 2009 at 12:50 PM, Devdatta dev.akh...@gmail.com wrote: Regarding , History enumeration -- I don't see why it should be part of CSP. A separate header - X-Safe-History can be used. 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. 2) The directives can share common infrastructure, like the reporting facilities. Adam ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Comments on the Content Security Policy specification
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 particular versions of which agents support the mix of CSP features they want to use, and what it means if a given browser only supports 2 of the 3 modules they want to use. If this means some more up-front pain for vendors in implementation costs vs. pushing more complexity to web developers, the former approach seems to be a lot less expensive in the net. Lucas. On Oct 20, 2009, at 1:42 PM, Collin Jackson wrote: 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 sites, but to provide content restrictions and help stop XSS (mostly content restrictions). Rolling all sorts of extra threats like history sniffing into CSP will make it huge and complex, and for not what was initially desired. (A complex CSP isn't so bad if it were modular, but I don't think 'wide-reaching' was the original aim for CSP). 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 (the CSP header syntax) and other modules they like such as XSSModule without feeling like they have to implement the ones they think aren't interesting. And they can experiment with their own modules without feeling like they're breaking the spec. One idea that might make a module CSP more approachable for vendors is to have a status page that shows the various modules, like this: https://wiki.mozilla.org/Security/CSP/Modules ___ 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: Comments on the Content Security Policy specification
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 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 particular versions of which agents support the mix of CSP features they want to use, and what it means if a given browser only supports 2 of the 3 modules they want to use. If this means some more up-front pain for vendors in implementation costs vs. pushing more complexity to web developers, the former approach seems to be a lot less expensive in the net. Lucas. On Oct 20, 2009, at 1:42 PM, Collin Jackson wrote: 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 sites, but to provide content restrictions and help stop XSS (mostly content restrictions). Rolling all sorts of extra threats like history sniffing into CSP will make it huge and complex, and for not what was initially desired. (A complex CSP isn't so bad if it were modular, but I don't think 'wide-reaching' was the original aim for CSP). 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 (the CSP header syntax) and other modules they like such as XSSModule without feeling like they have to implement the ones they think aren't interesting. And they can experiment with their own modules without feeling like they're breaking the spec. One idea that might make a module CSP more approachable for vendors is to have a status page that shows the various modules, like this: https://wiki.mozilla.org/Security/CSP/Modules ___ 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: Comments on the Content Security Policy specification
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 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 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 particular versions of which agents support the mix of CSP features they want to use, and what it means if a given browser only supports 2 of the 3 modules they want to use. If this means some more up-front pain for vendors in implementation costs vs. pushing more complexity to web developers, the former approach seems to be a lot less expensive in the net. Lucas. On Oct 20, 2009, at 1:42 PM, Collin Jackson wrote: 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 sites, but to provide content restrictions and help stop XSS (mostly content restrictions). Rolling all sorts of extra threats like history sniffing into CSP will make it huge and complex, and for not what was initially desired. (A complex CSP isn't so bad if it were modular, but I don't think 'wide-reaching' was the original aim for CSP). 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 (the CSP header syntax) and other modules they like such as XSSModule without feeling like they have to implement the ones they think aren't interesting. And they can experiment with their own modules without feeling like they're breaking the spec. One idea that might make a module CSP more approachable for vendors is to have a status page that shows the various modules, like this: https://wiki.mozilla.org/Security/CSP/Modules ___ 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: Comments on the Content Security Policy specification
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, Lucas Adamski lu...@mozilla.com wrote: 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 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 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 particular versions of which agents support the mix of CSP features they want to use, and what it means if a given browser only supports 2 of the 3 modules they want to use. If this means some more up-front pain for vendors in implementation costs vs. pushing more complexity to web developers, the former approach seems to be a lot less expensive in the net. Lucas. On Oct 20, 2009, at 1:42 PM, Collin Jackson wrote: 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 sites, but to provide content restrictions and help stop XSS (mostly content restrictions). Rolling all sorts of extra threats like history sniffing into CSP will make it huge and complex, and for not what was initially desired. (A complex CSP isn't so bad if it were modular, but I don't think 'wide-reaching' was the original aim for CSP). 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 (the CSP header syntax) and other modules they like such as XSSModule without feeling like they have to implement the ones they think aren't interesting. And they can experiment with their own modules without feeling like they're breaking the spec. One idea that might make a module CSP more approachable for vendors is to have a status page that shows the various modules, like this: https://wiki.mozilla.org/Security/CSP/Modules ___ 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: Comments on the Content Security Policy specification
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 module are protected against history enumeration attacks. Going forward, we want to keep the separation just as clear and simple. * This would require very clear and simply stated threat models for each module. Each module's threats should be (ideally) disjoint. * A module should be small and complete. We should make it clear why every part of the module is important for the given threat model. This would hopefully ensure that browser vendors either implement the whole module or none of it. (I.E implementing half of a module will give no security) I think this breakup of the spec into modules is useful to the webdevelopers (making it easier to understand) and easier for the browser vendors to implement. Regards Devdatta ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Comments on the Content Security Policy specification
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 20, 2009, at 14:53, Collin Jackson mozi...@collinjackson.com wrote: 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, Lucas Adamski lu...@mozilla.com wrote: 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 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 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 particular versions of which agents support the mix of CSP features they want to use, and what it means if a given browser only supports 2 of the 3 modules they want to use. If this means some more up-front pain for vendors in implementation costs vs. pushing more complexity to web developers, the former approach seems to be a lot less expensive in the net. Lucas. On Oct 20, 2009, at 1:42 PM, Collin Jackson wrote: 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 sites, but to provide content restrictions and help stop XSS (mostly content restrictions). Rolling all sorts of extra threats like history sniffing into CSP will make it huge and complex, and for not what was initially desired. (A complex CSP isn't so bad if it were modular, but I don't think 'wide-reaching' was the original aim for CSP). 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 (the CSP header syntax) and other modules they like such as XSSModule without feeling like they have to implement the ones they think aren't interesting. And they can experiment with their own modules without feeling like they're breaking the spec. One idea that might make a module CSP more approachable for vendors is to have a status page that shows the various modules, like this: https://wiki.mozilla.org/Security/CSP/Modules ___ 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
Versioning vs. Modularity (was Re: Comments on the Content Security Policy specification)
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 reason to split the existing functionality into modules. I'm not sure versioning is the best approach for web technologies. For example, versioning has been explicitly rejected for HTML, ECMAScript, and cookies. In fact, I can't really think of a successful web technology that uses versioning instead of extensibility. Maybe SSL/TLS? Even there, the modern approach is to advance the protocol with extensions (e.g., SNI). Adam ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Comments on the Content Security Policy specification
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 the model in the long run, as the APIs they govern will not be mutually exlusive. What if 3 different modules dictate image loading behaviors? What if the given user agent in a scenario does not implement the module where the most restrictive of the 3 policies is specified? Lucas On Oct 20, 2009, at 15:07 Devdatta dev.akh...@gmail.com wrote: 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 module are protected against history enumeration attacks. Going forward, we want to keep the separation just as clear and simple. * This would require very clear and simply stated threat models for each module. Each module's threats should be (ideally) disjoint. * A module should be small and complete. We should make it clear why every part of the module is important for the given threat model. This would hopefully ensure that browser vendors either implement the whole module or none of it. (I.E implementing half of a module will give no security) I think this breakup of the spec into modules is useful to the webdevelopers (making it easier to understand) and easier for the browser vendors to implement. Regards Devdatta ___ 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: Versioning vs. Modularity (was Re: Comments on the Content Security Policy specification)
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 against existing APIs. Other option I guess is not versioning and just breaking content periodically. Lucas On Oct 20, 2009, at 15:27, Adam Barth abarth-mozi...@adambarth.com wrote: 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 reason to split the existing functionality into modules. I'm not sure versioning is the best approach for web technologies. For example, versioning has been explicitly rejected for HTML, ECMAScript, and cookies. In fact, I can't really think of a successful web technology that uses versioning instead of extensibility. Maybe SSL/TLS? Even there, the modern approach is to advance the protocol with extensions (e.g., SNI). Adam ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Module granularity (Re: Comments on the Content Security Policy specification)
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 in the long run (esp. when combined with fragmented implementation by user agents). Lucas. On Oct 20, 2009, at 15:49, Adam Barth abarth-mozi...@adambarth.com wrote: On Tue, Oct 20, 2009 at 3:35 PM, Lucas Adamski lu...@mozilla.com wrote: The problem with modules I see is they will complicate the model in the long run, as the APIs they govern will not be mutually exlusive. What if 3 different modules dictate image loading behaviors? What if the given user agent in a scenario does not implement the module where the most restrictive of the 3 policies is specified? This seems like a question of granularity. Presumably a decomposition that has three modules competing to control image loads is too granular. There seem to be some clear wins to modularizing the current spec. For example, the reporting infrastructure seems independent of whether you can block XMLHttpRequest targets. Adam ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Comments on the Content Security Policy specification
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 lu...@mozilla.com: 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 the model in the long run, as the APIs they govern will not be mutually exlusive. What if 3 different modules dictate image loading behaviors? What if the given user agent in a scenario does not implement the module where the most restrictive of the 3 policies is specified? Lucas On Oct 20, 2009, at 15:07 Devdatta dev.akh...@gmail.com wrote: 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 module are protected against history enumeration attacks. Going forward, we want to keep the separation just as clear and simple. * This would require very clear and simply stated threat models for each module. Each module's threats should be (ideally) disjoint. * A module should be small and complete. We should make it clear why every part of the module is important for the given threat model. This would hopefully ensure that browser vendors either implement the whole module or none of it. (I.E implementing half of a module will give no security) I think this breakup of the spec into modules is useful to the webdevelopers (making it easier to understand) and easier for the browser vendors to implement. Regards Devdatta ___ 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
ClickJackingModule (was Re: Comments on the Content Security Policy specification)
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 instead of strings. Adam On Tue, Oct 20, 2009 at 6:05 PM, Devdatta dev.akh...@gmail.com wrote: 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 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: ClickJackingModule (was Re: Comments on the Content Security Policy specification)
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 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 instead of strings. Adam On Tue, Oct 20, 2009 at 6:05 PM, Devdatta dev.akh...@gmail.com wrote: 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 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
