Re: Content Security Policy feedback
You guys should add Arun + Jonas to this conversation if you can. --Chris ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy feedback
Sid Stamm wrote: Gerv: what are your thoughts on (mis)use of the Report-URI to determine which browsers support CSP? For example, given a policy X- Content-Security-Policy: allow self, Report-URI http://self.com/ report and a tag served script src='http://forbidden.com/js', a report would be generated. Assuming the report URI and the page containing the violation are in the same domain, cookies could be used to connect the report to a specific client. It seems to me that unless client browsers *never* send CSP-related data to the server then the server can ultimately determine which clients are using CSP. I have no objection in principle to servers knowing that clients have CSP capability. What I object to is bulking up every HTTP request with that information, or making the protocol or system more complicated in order to allow people to do things they shouldn't be doing (like relying on it as a first line of defence). Gerv ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy feedback
bsterne wrote: I think that CSP should be considered part of the browser security model. Mike and others have made the excellent point that there are significant costs to bear for a website that wants to start using this model: policy development as well as migrating inline scripts to external script files. Websites will not be willing to pay this cost if user agents are not strongly committed to enforcing the policies. We won't be able to make security guarantees like XSS will never happen on your site, but we can provide smaller guarantees like inline script will not execute in this page if the CSP header is sent. I completely agree that we should make these guarantees, in the sense that if that doesn't work, it's a bug :-) That's not the sort of guarantee I'm objecting to. The sort I'm objecting to is you don't have to validate and escape user input properly because even if you let a script tag through accidentally, CSP will catch it and save you. Some understandings of CSP being strongly part of the browser security model would have us making such guarantees. And I think they would be a mistake. If CSP being strongly part of the browser security model just means we guarantee that it does what it says on the tin then I have no problem with it :-) My reduced commitment to guarantees was not designed as an ass-covering measure for shoddy coding ;-) Gerv ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy feedback
Sorry I haven't been more vocal on this thread lately. I think it's important that we keep our momentum moving forward here if we hope to get something meaningful implemented any time soon. I am getting the sense that we aren't in agreement on one or two of the fundamental goals of this project and I think it potentially jeopardizes overall progress if we are working with different base assumptions. My near-term goal is to start driving toward a stable design (if not specification) for CSP. The design is certainly still open for comments and feedback, but those discussions will be easier to resolve after we've settled the issue of project goals. More below... On Dec 23 2008, 7:34 am, Gervase Markham g...@mozilla.org wrote: I am not arguing we should make CSP work a random 50% of the time. I am arguing that CSP is not a security model, it's a phew, I would have just got stuffed, but it saved me this time model. Security models are things you rely on. CSP is a second line of defence for when your security model fails, and it doesn't promise to save your ass every time. I think that CSP should be considered part of the browser security model. Mike and others have made the excellent point that there are significant costs to bear for a website that wants to start using this model: policy development as well as migrating inline scripts to external script files. Websites will not be willing to pay this cost if user agents are not strongly committed to enforcing the policies. We won't be able to make security guarantees like XSS will never happen on your site, but we can provide smaller guarantees like inline script will not execute in this page if the CSP header is sent. I have previously agreed with Gerv's belt-and-(suspenders|braces) logic with regard to CSP as it had twofold appeal to me: 1) it is consistent with the defense-in-depth approach found elsewhere in computer security, and 2) it provided an escape hatch from design flaws, implementation bugs, or other deficiencies later discovered with the model. It appears now, though, that this issue is impeding us a bit and I am going to weigh in on the side of stronger commitment to policy enforcement. Perhaps a stronger design is produced as the result of a firm commitment to CSP as a part of the browser security model (or perhaps it is required by such a commitment). ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy feedback
Sid Stamm wrote: Gervase Markham g...@mozilla.org wrote: Security is a multi-faceted beast. Point taken, and I agree, it was a crappy analogy. Again, CSP is here being used as a front line of defence, and it shouldn't be. I agree with you... optimally, CSP should not be front-line defense. But for it to be helpful in practice, there must be a motivation for people to put it on their sites. 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. Another feature of CSP is herd immunity - it doesn't have to be used by everyone to be helpful. Sorry, I realise that in hindsight I was ambiguous here. I meant that not all end-users have to use it for it to be helpful in the case of a particular site which is using it. I say this because once the site owner is warned of the problem, he can fix it. If no-one has CSP, it may take much longer for people to notice the compromise. Gerv ___ 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: Content Security Policy feedback
On Jan 12, 5:53 am, Gervase Markham g...@mozilla.org wrote: not all end-users have to use it for it to be helpful in the case of a particular site which is using it. I say this because once the site owner is warned of the problem, he can fix it. If no-one has CSP, it may take much longer for people to notice the compromise. Of course, unless the site breaks in a noticeable way when violations of CSP occur, there is no additional help for the site developer... and I don't believe that CSP is intended to have a violation reporting mechanism. Additionally, it is my impression that a lot of attacks stopped by CSP would break un-noticed. For example, a cross-site exploit that simply embeds a script and steals cookies would likely not modify the page visually, so whether or not it fails, the end-user wouldn't notice. Maybe something to add value to CSP support would be a CSP developer mode or warning logo somewhere in the browser that alerts the end-user when a policy is violated. That would indeed be an easy-addon, and perhaps testers could just flip it on for sites they fool with on a daily basis. Or do we want phone-home features for CSP so the browser will automatically tell a site when its policy is violated? This sounds like it could be abused to help sites identify which browsers support CSP (essentially providing that 'this-browser-supports-csp' flag you're arguing against). -Sid ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy feedback
Sid Stamm wrote on 1/12/2009 12:52 PM: Or do we want phone-home features for CSP so the browser will automatically tell a site when its policy is violated? It already has this feature, see #6: http://people.mozilla.org/~bsterne/content-security-policy/details.html - Bil ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy feedback
Sid Stamm wrote: I'm not sure I agree with that... take for instance a browser that only supports SSL v2 (and not 3): That's a difficult for instance to accept, because there aren't any. At least, not that anyone uses. a site concerned with avoiding MITM attacks might serve different content (or none) to someone whose browser only supports SSL v2, and serve all the site's content to someone whose browser supports v3. That doesn't warrant blocking content to all visitors regardless of what security constructs their browser supports. Right. In that far-fetched scenario, they might. But the security provided by SSL (privacy, authentication) is very different to the security provided by CSP (anti-XSS), so the analogy doesn't hold. Security is a multi-faceted beast. I see your point. One would hope X is not *designed* to be unsafe, but it might not be rock-solid, with a history of security issues (like Flash). The webmaster might not feel completely comfortable with his mastery of it, so only feels comfortable providing Flash- based content to people whose browsers will help protect them. In which case, for the forseeable future, he won't be providing it to many people. :-) Again, CSP is here being used as a front line of defence, and it shouldn't be. Another feature of CSP is herd immunity - it doesn't have to be used by everyone to be helpful. Gerv ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy feedback
Lucas Adamski wrote: Developers rely on the browser security model in countless ways already. A fundamental attribute of security models is reliability. I am not arguing we should make CSP work a random 50% of the time. I am arguing that CSP is not a security model, it's a phew, I would have just got stuffed, but it saved me this time model. Security models are things you rely on. CSP is a second line of defence for when your security model fails, and it doesn't promise to save your ass every time. Gerv ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy feedback
Sid Stamm wrote: Gervase Markham wrote: If a server is to rely on CSP to reliably enforce security constraints If it's doing that, it's broken. CSP is explicitly not designed for this. (As I understand it.) Maybe it's not completely bad for browsers to advertise whether or not they support CSP (and which versions). There's a benefit for web developers who can decide to serve more restricted/filtered content to browsers that won't catch them when they fall. If there's additional filtering they know how to do, they should be doing it for everyone. example, consider a webmaster who is just learning some new technology X may not be comfortable enough to serve X content without a safety net that CSP provides, but is being pressured to add features to his site. Then he shouldn't use X. (Who designed X to be unsafe by default? Go shoot them. :-) Gerv ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy feedback
Lucas Adamski wrote: Well, I think any security feature/model has to have some properties that are reliable. So CSP may not prevent XSS is the blanket sense, but it still needs to be able to enforce some set of restrictions that the developer can rely upon. Your second sentence doesn't follow from your first, in this context. Yes, if CSP promises it'll prevent exact attack scenario X, it should prevent X, and if it doesn't prevent X, it's a bug. (But all that's really saying is that it's deterministic.) No, that doesn't mean that developers should rely on a particular browser preventing attack X. There may be a bug, the user may have turned it off, there may be a very similar attack Y using the same flaw which CSP can't prevent, and so on. Gerv ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy feedback
It seems to me that version-compatibility announcement is helpful unless CSP is intended to be a short-lived or rarely-used security construct (which I gather is not the point). It is very likely that CSP's governing scope will change in the future, or an additional policy may be created to govern other pieces. It is fairly likely that different, incompatible policy-version support may need to be treated differently by the web server. In fact, supported version announcement is probably necessary, not just useful, if implementations of CSP are initially rolled out in browser add-ons; suddenly there's the possibility of multiple browser/ add-on version combinations, especially when people delay updating browsers or updating plugins when prompted (old-browser + new-addon, new-browser + old-addon, etc). In these scenarios user-agent profiling just won't work reliably. Also, it's not clear we should burden the web site developers to stay up-to-date on which browsers support which policies; it might be difficult to track which agents support which engines, especially for unknown or niche browsers. Instead, it might be ideal to explicitly tell the server what is supported so regardless of the user-agent, the server can be fairly confident it serves an appropriate policy. A reasonable approach to specify the CSP version might be seen in the Accept-Charset header, or really any of the Accept-* request headers. It need not be present, but if it is, such an Accept-Security-Policy request header can contain which versions the user agent supports (e.g., CSP-1.0), and can be comma-separated in case multiple versions or multiple policies are supported. Another option would be to shove the supported CSP versions into the user agent string, but that's a nasty abuse of the User-Agent header (though arguably the security policy enforcement is part of the platform on which web apps will run). -Sid ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy feedback
Gervase Markham wrote: If a server is to rely on CSP to reliably enforce security constraints If it's doing that, it's broken. CSP is explicitly not designed for this. (As I understand it.) Maybe it's not completely bad for browsers to advertise whether or not they support CSP (and which versions). There's a benefit for web developers who can decide to serve more restricted/filtered content to browsers that won't catch them when they fall. This benefit is not there if the browser's don't advertise what they will enforce. For example, consider a webmaster who is just learning some new technology X may not be comfortable enough to serve X content without a safety net that CSP provides, but is being pressured to add features to his site. If a client doesn't support CSP, his server can simply not serve any script content that he isn't sure about, but when CSP is present and can be enforced, he has that to fall back on and can serve experimental stuff. While in an ideal world, all developers should understand how all the code their site serves will behave in every situation, but I doubt this is the case in reality, especially for smaller, feature-driven sites. I can see both sides of this issue, though. It is not healthy to rely on CSP for a primary layer of security, especially since it will take some time for CSP to be adopted widely (and we *really* don't want to encourage sloppy design). -Sid ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy feedback
Bil Corry wrote: No, so that in the event CSPv2 is incompatible with CSPv1, it won't require two response headers to be sent to every client. Instead, since the browser tells the server which version of CSP it's accepting, the server can send back the CSP header in the most recent format that both the client and server understand (e.g. server knows CSPv2, client knows CSPv3, server sends CSPv2 header). That makes no sense. You are saying that servers won't send any policy at all, now, because in the future they might have to send two headers? Gerv ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy feedback
bsterne wrote: I think what Lucas is saying is that servers won't send policy to clients who don't announce that they support CSP. To save 60 bytes in a header? Gerv ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy feedback
Gervase Markham wrote on 12/3/2008 4:56 PM: bsterne wrote: I think what Lucas is saying is that servers won't send policy to clients who don't announce that they support CSP. To save 60 bytes in a header? No, so that in the event CSPv2 is incompatible with CSPv1, it won't require two response headers to be sent to every client. Instead, since the browser tells the server which version of CSP it's accepting, the server can send back the CSP header in the most recent format that both the client and server understand (e.g. server knows CSPv2, client knows CSPv3, server sends CSPv2 header). - Bil ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy feedback
On Nov 22, 2:03 pm, Lucas Adamski [EMAIL PROTECTED] wrote: Yes, my understanding is that Access Control is actually intended as a generic cross-site server policy mechanism, and XHR is just its first implementation. Anne confirmed that it's not intended to be XHR-only, however it's not intended for all types of requests either. He specifically said it would not work for iframe due to cross-site scripting issues. - Bil ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy feedback
I think this is true, but it kind of depends on how you look at it. I think sometimes different types of cross-domain operations can get conflated together: * cross-domain scripting - when code in one domain has the ability to access another domain's code or DOM * cross-domain data importing - transferring data from the context of one domain into another domain (XHR with AC, stylesheets) * cross-domain content loading - hands-off content loading operations such as IFRAME and IMG tags that leave content in their respective security domains--aka embedding In this (conveniently simplified) model, since iframe is a content loading operation, it doesn't need Access Control. Nor am I sure what it would really even mean to apply Access Control to it (would it be permitting data importing or scripting?) Probably the biggest fly in my otherwise nicely-simple ointment is SCRIPT SRC=. Is it cross-domain scripting or data importing? It may seem like scripting at first blush, but you may not have even instantiated any code from the source domain, and in the end its not much different than loading data via XHR+AC and then calling eval() on it. So I would argue that even SCRIPT SRC= is a data import operation, just one that is (alas) permitted by default and automatically evals everything it loads. So perhaps we are just agreeing insofar that Access Control should never govern cross-domain scripting. Whether it could/should be extended to govern (opt-out of) cross-domain loading/embedding is an interesting one. Thanks, Lucas. Bil Corry wrote: On Nov 22, 2:03 pm, Lucas Adamski [EMAIL PROTECTED] wrote: Yes, my understanding is that Access Control is actually intended as a generic cross-site server policy mechanism, and XHR is just its first implementation. Anne confirmed that it's not intended to be XHR-only, however it's not intended for all types of requests either. He specifically said it would not work for iframe due to cross-site scripting issues. - Bil ___ 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: Content Security Policy feedback
On Nov 20, 4:37 pm, bsterne [EMAIL PROTECTED] wrote: On Nov 17, 2:19 pm, Bil Corry [EMAIL PROTECTED] wrote: (1) Something that appears to be missing from the spec is a way for the browser to advertise to the server that it will support Content Security Policy, possibly with the CSP version. By having the browser send an additional header, it allows the server to make decisions about the browser, such as limiting access to certain resources, denying access, redirecting to an alternate site that tries to mitigate using other techniques, etc. Without the browser advertising if it will follow the CSP directives, one would have to test for browser compliance, much like how tests are done now for cookie and JavaScript support (maybe that isn't a bad thing?). This isn't a bad idea, as I have seen this sort of compatibility level used successfully elsewhere. If future changes are made to the model which would define restrictions for new types of content (e.g. video), or which would affect the default behaviors for how content is allowed to load, then it will be useful to servers to have their clients' CSP version information. If we are going to add this to the model, then we should do so from the beginning to avoid the potentially messy browser compliance testing that would result after the first set of changes. I personally see value there for the website, but if 99.9% of websites will never do anything with the header, then it probably isn't worthwhile (or it may take version 2 before the need is evident). The big challenge here is making sure the CSP announcement header can not be spoofed via XHR, so to that end, I'd recommend prefixing the header name with Sec- such as Sec-Content-Security-Policy -- the latest draft of XHR2 specifies that any header beginning with Sec- is not allowed to be overwritten with setRequestHeader(): http://www.w3.org/TR/XMLHttpRequest2/#setrequestheader Of course, XHR2 would have to be implemented in the browsers first in order to take advantage of the requirement. (2) Currently the spec allows/denies based on the host name, it might be worthwhile to allow limiting it to a specific path as well. For example, say you use Google's custom search engine, one way to implement it is to use a script that sits onwww.google.com(e.g.http://www.google.com/coop/cse/brand?form=cse-search-box〈=en). By having an allowed path, you could prevent loading other scripts from thewww.google.comdomain. I don't have a strong opinion on this one. My initial reaction is that it adds complexity to the model, but perhaps complexity that's warranted if people feel it's a useful feature. Do you have some specific use cases to share which would demonstrate the usefulness of your suggestion? I don't have a specific use case, I'm thinking more of the edge cases where content is allowed from a domain that allows a multitude of third-party content. Maybe this is something to explore for v2 if warranted. (3) Currently the spec focuses on the host items -- has any thought be given to allowing CSP to extend to sites being referenced by host items? That is, allowing a site to specify that it can't be embedded on another site via frame or object, etc? I imagine it would be similar to the Access Control for XS-XHR[2]. I would agree with Gerv, that this feels a bit out of scope for this particular proposal. Then maybe something to consider down the road. It would be useful to prevent hot linking and clickjacking . - Bil ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy feedback
Bil Corry wrote: Giorgio Maone mentioned CSP on the OWASP Intrinsic Security list[1] and I wanted to provide some feedback. (1) Something that appears to be missing from the spec is a way for the browser to advertise to the server that it will support Content Security Policy, possibly with the CSP version. That's intentional. CSP is a backstop solution, not front-line security. If you are depending on the presence of CSP, as the lolcats say, U R Doin It Wrong. (2) Currently the spec allows/denies based on the host name, it might be worthwhile to allow limiting it to a specific path as well. For example, say you use Google's custom search engine, one way to implement it is to use a script that sits on www.google.com (e.g. http://www.google.com/coop/cse/brand?form=cse-search-boxamp;lang=en). By having an allowed path, you could prevent loading other scripts from the www.google.com domain. For this and the next one, I'll wait for bsterne to reply, as he's doing the implementation and speccing work. (3) Currently the spec focuses on the host items -- has any thought be given to allowing CSP to extend to sites being referenced by host items? That is, allowing a site to specify that it can't be embedded on another site via frame or object, etc? I imagine it would be similar to the Access Control for XS-XHR[2]. I would suspect that would be out of scope. Gerv ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
