Re: Content Security Policy - final call for comments
One option is to meet in the middle: by default the meta tag is disabled, but the hosting provider can enable it via the X-Content-Security-Policy header; that way those who want the risk of it can still choose to use it. Otherwise, +1 for removing meta tag support. - Bil Brandon Sterne wrote on 6/30/2009 10:50 AM: > (copying the dev-security newsgroup) > > Hi Ignaz, > > Thanks for the feedback. The "spoofed security indicators" from an > injected CSP meta tag is a fair point and one I haven't thought of > previously. I'm not sure if browsers will implement such visual > indicators for CSP because it may confuse users. This is still a valid > point, though, and we've struggled with the idea of tag policy > from the beginning. The idea is to enable sites which can't set headers > to use CSP, but the reward might not be worth the risk. In fact, Sid, > one of the engineers implementing CSP has proposed removing this from > the design: > http://blog.sidstamm.com/2009/06/csp-with-or-without-meta.html > > If there are no major objections to doing so, it looks like you'll get > your way :-) > > Cheers, > Brandon > > > ignazb wrote: >> Hello, >> >> I just read some of the documentation about CSP and I must say it >> looks promising. However, I think there are some "flaws" in the spec. >> -) I think it is a bad idea to allow the use of a meta tag for CSP >> policy-declaration. If, for example, you decided to show a symbol in >> the browser that indicates that the site is CSP secured, it would not >> be possible to tell whether the CSP policy comes from the server via a >> HTTP header or from an attacker who just injected it (unless, of >> course, you display where the CSP policy came from). So if a user >> visits a site and sees it is CSP "secured" (although an attacker >> inserted the tag allowing the execution of scripts from his site) she >> could decide to turn on JavaScript although the site is inherently >> unsafe. >> -) There should probably also be a way to restrict the contents of >> meta tags in a website. If, for example, an attacker inserts a meta >> for a HTTP redirect, he could redirect users to his own website, even >> with CSP enabled. >> >> -- Ignaz > ___ > 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 - final call for comments
(copying the dev-security newsgroup) Hi Ignaz, Thanks for the feedback. The "spoofed security indicators" from an injected CSP meta tag is a fair point and one I haven't thought of previously. I'm not sure if browsers will implement such visual indicators for CSP because it may confuse users. This is still a valid point, though, and we've struggled with the idea of tag policy from the beginning. The idea is to enable sites which can't set headers to use CSP, but the reward might not be worth the risk. In fact, Sid, one of the engineers implementing CSP has proposed removing this from the design: http://blog.sidstamm.com/2009/06/csp-with-or-without-meta.html If there are no major objections to doing so, it looks like you'll get your way :-) Cheers, Brandon ignazb wrote: > Hello, > > I just read some of the documentation about CSP and I must say it > looks promising. However, I think there are some "flaws" in the spec. > -) I think it is a bad idea to allow the use of a meta tag for CSP > policy-declaration. If, for example, you decided to show a symbol in > the browser that indicates that the site is CSP secured, it would not > be possible to tell whether the CSP policy comes from the server via a > HTTP header or from an attacker who just injected it (unless, of > course, you display where the CSP policy came from). So if a user > visits a site and sees it is CSP "secured" (although an attacker > inserted the tag allowing the execution of scripts from his site) she > could decide to turn on JavaScript although the site is inherently > unsafe. > -) There should probably also be a way to restrict the contents of > meta tags in a website. If, for example, an attacker inserts a meta > for a HTTP redirect, he could redirect users to his own website, even > with CSP enabled. > > -- Ignaz ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy - final call for comments
Based on feedback and resulting discussions, I think it is best that we proceed with the User-Agent [1] product token [2] approach for CSP versioning. It will only add ~5 bytes, e.g. CSP/1, to the U-A string and will be easily parsable by servers. I am going to update the CSP spec to reflect this addition. Cheers, Brandon [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.43 [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.8 On 4/10/09 10:32 AM, Sid Stamm wrote: > If we advertise the version at all (I'm still on the fence here), I > think maybe putting CSP version into the User-Agent header might be > appropriate, since CSP is technically a capability of the user agent. > http://tools.ietf.org/html/rfc2616#section-14.43 > > If indeed the UA gets scrubbed by someone concerned about privacy (or a > proxy/firewall/etc), it seems appropriate that this advertisement of a > user-agent's capability (the CSP version) should get scrubbed too. > > So the UA string is harder to parse than a header containing only this > version, but the syntax is fairly straightforward in RFC 2616. Also, > I'm not seeing a Flash-Version header, or a header that alone advertises > any other browser capabilities, so unless we want to make a new header > and put *all* advertised capabilities in it, User-Agent seems the best > choice. > > Cheers, > Sid > > ___ > 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 - final call for comments
On Apr 2, 5:12 pm, Brandon Sterne wrote: > For those of you who have followed the progression of CSP, you > have seen the model grow quite a bit in complexity. I'd really like to see some real-world examples to illustrate how complex this policy actually gets in practice. What would the policy be for, say, CNN.com? What code changes would be necessary to make the site continue to work with CSP? Terri ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy - final call for comments
On 4/15/09 1:32 AM, Gervase Markham wrote: > Why does the CSP technology get to advertise and version itself in this > way when no other technology the browser supports does? If we allow CSP > to send version information in every HTTP request, what other > technologies are going to want it? "I support ". "I support > HTML5". Etc. I think the slippery slope argument has validity here. The support of or HTML5 by a client does not have the same security implications as the support of CSP. If a client does not support and a site serves it to them, there is no risk to the client, which can passively ignore the content. If a client does not support CSP and a site serves them untrusted content, there is a higher XSS risk to that client than to one which does support CSP. > Why not start versioning when we reach version 2 (i.e. there are two > versions to distinguish), if that ever happens? Another benefit of the version string that we've discussed is the ability for a client to signal that CSP is disabled presently (by removing the string). In those cases, a site may want to restrict which content is served to that client. -Brandon ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy - final call for comments
On 10/04/09 16:46, Brandon Sterne wrote: I'm not 100% thrilled with the idea either, mostly because parsing the U-A string could be challenging for some sites. But it does seems to be the least bad idea I've heard. We can certainly minimize U-A bloat by making our subproduct something like "CSP/1". I'm certainly open to other suggestions, though. Why does the CSP technology get to advertise and version itself in this way when no other technology the browser supports does? If we allow CSP to send version information in every HTTP request, what other technologies are going to want it? "I support ". "I support HTML5". Etc. I think the slippery slope argument has validity here. Why not start versioning when we reach version 2 (i.e. there are two versions to distinguish), if that ever happens? Gerv ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy - final call for comments
That depends on your definition of reliable. CSP not a panacea, but it is expected to be able to enforce a set of restrictions that are reliable. Reliability is an aspect of any feature in the browser I image so its not like we can dodge that. To rely on those particular restrictions sites will have to try to determine if the UA supports it, which it will try to do (poorly) by mapping UA versions to CSP support. I don't mean to try to short circuit the conversation around this but I feel like we've gone several rounds on versioning and I'm trying to figure out if there are any additional issues we haven't already discussed. If the major objection is that developers may some day actually rely on CSP to provide a set of security mitigation then I can honestly say that's a problem I'd be happy to have. Thanks, Lucas. On Apr 10, 2009, at 7:06 AM, Gervase Markham wrote: But by design, it can't be entirely reliable, because it can't read the developer's mind. Or have you got the ESP module working properly now? :-) ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy - final call for comments
On 4/10/09 9:50 AM, Bil Corry wrote: http://groups.google.com/group/mozilla.dev.security/browse_thread/thread/c0f1a44e4fb98859#anchor_ffeba39158c82a91 While I do like the idea of an Accept-Header header for capability-advertising uses, it's not yet implemented. And I fear if it were implemented, it may encourage adding too many X-headers to the request ... which is orthogonal to our goal in avoiding a new header for CSP versioning. There's already tremendous pressure to keep the number of HTTP headers low. If we were already sending Accept-Header, I'd jump right on it as a place to put the CSP version, but I don't really think it's wise to add this new header with only CSP using it for now. If we advertise the version at all (I'm still on the fence here), I think maybe putting CSP version into the User-Agent header might be appropriate, since CSP is technically a capability of the user agent. http://tools.ietf.org/html/rfc2616#section-14.43 If indeed the UA gets scrubbed by someone concerned about privacy (or a proxy/firewall/etc), it seems appropriate that this advertisement of a user-agent's capability (the CSP version) should get scrubbed too. So the UA string is harder to parse than a header containing only this version, but the syntax is fairly straightforward in RFC 2616. Also, I'm not seeing a Flash-Version header, or a header that alone advertises any other browser capabilities, so unless we want to make a new header and put *all* advertised capabilities in it, User-Agent seems the best choice. Cheers, Sid ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy - final call for comments
Brandon Sterne wrote on 4/10/2009 10:46 AM: > I'm not 100% thrilled with the idea either, mostly because parsing the > U-A string could be challenging for some sites. But it does seems to be > the least bad idea I've heard. We can certainly minimize U-A bloat by > making our subproduct something like "CSP/1". I'm certainly open to > other suggestions, though. I proposed an alternative earlier in the thread: http://groups.google.com/group/mozilla.dev.security/browse_thread/thread/c0f1a44e4fb98859#anchor_ffeba39158c82a91 - Bil ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy - final call for comments
On 4/10/09 7:06 AM, Gervase Markham wrote: >> If sites are relying on CSP for XSS protection, then perhaps they would >> want to serve only "trusted content" to non-CSP users. > > If you have a mechanism for making content "trusted", why not use it all > the time? You don't turn off your HTML sanitizer for CSP-supporting > browsers. I think the point is that sites won't have 100% confidence in their HTML sanitizer. The HTML scrubber might have bugs, which CSP provides mitigation for. This raises the confidence level to a point where sites can be comfortable serving user-generated content, etc. because they know there are policies limiting what that content can do. >> In reality, as CSP becomes more mature and well-understood, sites will >> rely on it for XSS mitigation. It's inevitable that if we put a >> reliable product out there sites will rely upon it. > > But by design, it can't be entirely reliable, because it can't read the > developer's mind. Or have you got the ESP module working properly now? :-) Not reliable in the sense that "we guarantee there will never be XSS in your site". I site can still write code with vulnerabilities even under CSP. By reliable, I meant that the behavior will be consistent and patterns of effective use for XSS mitigation will develop. >> We're somewhat averse to >> adding a request header that would only carry the version info, so >> that's why we're looking for an existing request header that can carry >> this info. > > I really don't think UA is the right choice. Microsoft are bloating UAs > with .NET versions, and that's making people unhappy. I'm not 100% thrilled with the idea either, mostly because parsing the U-A string could be challenging for some sites. But it does seems to be the least bad idea I've heard. We can certainly minimize U-A bloat by making our subproduct something like "CSP/1". I'm certainly open to other suggestions, though. -Brandon ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy - final call for comments
On 08/04/09 23:09, Sid Stamm wrote: Additionally, knowing the portion of users whose browsers enforce CSP (and thus are benefiting from the minimal effort put into serving a CSP header) might be an interesting metric that web admins can present to their managers. ;) I don't think you need a CSP version number to get those stats. As Brandon says, there are other ways to measure support if you really want to. Gerv ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy - final call for comments
On 08/04/09 21:49, Brandon Sterne wrote: Defining a new header seems like a non-starter to me. We are going to be hard-pressed to get one new header standardized, so throwing one away seems very wasteful. As I said, I think the possibility of needing a breaking change in syntax is tiny. If sites are relying on CSP for XSS protection, then perhaps they would want to serve only "trusted content" to non-CSP users. If you have a mechanism for making content "trusted", why not use it all the time? You don't turn off your HTML sanitizer for CSP-supporting browsers. In reality, as CSP becomes more mature and well-understood, sites will rely on it for XSS mitigation. It's inevitable that if we put a reliable product out there sites will rely upon it. But by design, it can't be entirely reliable, because it can't read the developer's mind. Or have you got the ESP module working properly now? :-) But our header is only sent as a response header, so would not be useful for sending version info with client requests. Yeah, duh. Not sure what I was thinking there. Sorry. We're somewhat averse to adding a request header that would only carry the version info, so that's why we're looking for an existing request header that can carry this info. I really don't think UA is the right choice. Microsoft are bloating UAs with .NET versions, and that's making people unhappy. Gerv ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy - final call for comments
On 4/8/09 1:49 PM, Brandon Sterne wrote: If sites are relying on CSP for XSS protection, then perhaps they would want to serve only "trusted content" to non-CSP users. Additionally, knowing the portion of users whose browsers enforce CSP (and thus are benefiting from the minimal effort put into serving a CSP header) might be an interesting metric that web admins can present to their managers. ;) -Sid ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy - final call for comments
On 4/8/09 12:07 PM, Gervase Markham wrote: > On 07/04/09 18:02, Brandon Sterne wrote: >> 1. Bugs may be present in the CSP design which require future >> compatibility breakage. These obviously cannot be foreseen and, though >> we desire it, we can't guarantee forward compatibility. > > There are two sorts of possible breakage - syntax and functional. I > can't see us needing to throw away the syntax and, if we did, we'd just > define a new header. So no issues there. And functional breakage comes > into your second category anyway. Defining a new header seems like a non-starter to me. We are going to be hard-pressed to get one new header standardized, so throwing one away seems very wasteful. >> 3. We arguably want to have a pref for users to turn off CSP (for >> testing or otherwise). It would be useful to have the version number >> available as a means to communicate to the site that, even though the >> client supports CSP by default, CSP has been disabled on this client. > > Why is that useful information? If sites are relying on CSP for XSS protection, then perhaps they would want to serve only "trusted content" to non-CSP users. > I'm actually against making it easy for servers to "detect" if CSP is > supported, because if we make it particularly easy, content authors will > start relying on it as their only defence rather than using it as a > backup. "We don't need to check for XSS holes, we use CSP." That would > be bad. Of course, we can't stop them putting together fragile > User-Agent lists, but sites which do that are broken anyway, as the web > design community has been saying for years. In reality, as CSP becomes more mature and well-understood, sites will rely on it for XSS mitigation. It's inevitable that if we put a reliable product out there sites will rely upon it. CSP won't cause input sanitization, etc. to be removed from Security Best Practices, but it will be a standard part of the browser security model, I imagine. >> I looked at each of the HTTP Header Field Definitions and my preference >> for communicating the CSP version is to add a product token [1] to the >> User-Agent [2] string. This would add only a few bytes to the U-A and >> it saves us the trouble of having to go through IETF processes of >> creating a new request header. > > I'd much rather have a "\d+;" at the start of the header. Missing > implies version 1. But our header is only sent as a response header, so would not be useful for sending version info with client requests. We're somewhat averse to adding a request header that would only carry the version info, so that's why we're looking for an existing request header that can carry this info. -Brandon ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy - final call for comments
Gervase Markham wrote on 4/8/2009 2:07 PM: > On 07/04/09 18:02, Brandon Sterne wrote: > I'm actually against making it easy for servers to "detect" if CSP is > supported, because if we make it particularly easy, content authors will > start relying on it as their only defence rather than using it as a > backup. "We don't need to check for XSS holes, we use CSP." That would > be bad. Of course, we can't stop them putting together fragile > User-Agent lists, but sites which do that are broken anyway, as the web > design community has been saying for years. It seems unlikely that responsible web developers would rely entirely on CSP, especially initially, since not all UAs will support it. And if the developer really does choose to rely entirely on CSP, there isn't much we can do -- any developer with two domains can easily test if the client supports CSP, request header or no header. I think the stronger likelihood is that the developer won't use CSP at all -- their site will still work regardless. Providing a CSP header that can be measured to show it's worth the effort to learn and implement will be a much stronger incentive. In summary, given the number of XSS holes out there, if the developer chooses to rely entirely on CSP to protect them, that's far better than not using CSP at all. The biggest threat to CSP is not over-reliance, but rather under-utilization. - Bil ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy - final call for comments
On 07/04/09 18:02, Brandon Sterne wrote: 1. Bugs may be present in the CSP design which require future compatibility breakage. These obviously cannot be foreseen and, though we desire it, we can't guarantee forward compatibility. There are two sorts of possible breakage - syntax and functional. I can't see us needing to throw away the syntax and, if we did, we'd just define a new header. So no issues there. And functional breakage comes into your second category anyway. 2. New types of content (per your example) or new web APIs may be added in the future which don't shoehorn nicely into one of our current policy buckets. If we have to add another policy directive in the future, then it will violate the policy syntax in older versions which will cause them to fail closed (according to the current design). But the old browsers also won't support the new APIs/whatever. If we add a <3dcanvas> element to Firefox and control it with 3dcanvas-src, then old browsers won't understand the element, and so ignore it. And so if the browser didn't understand 3dcanvas-src either, that's no big deal. CSP should specify that unknown directives are ignored. That's a fairly common way to deal with this problem (CSS, HTML etc.). The only problem would be if an existing browser feature acquires specific restrictions when it used to be covered by "all". In that case, users of old browsers would get less protection - but they had that anyway, because their CSP implementation doesn't support the extra restriction. 3. We arguably want to have a pref for users to turn off CSP (for testing or otherwise). It would be useful to have the version number available as a means to communicate to the site that, even though the client supports CSP by default, CSP has been disabled on this client. Why is that useful information? I'm actually against making it easy for servers to "detect" if CSP is supported, because if we make it particularly easy, content authors will start relying on it as their only defence rather than using it as a backup. "We don't need to check for XSS holes, we use CSP." That would be bad. Of course, we can't stop them putting together fragile User-Agent lists, but sites which do that are broken anyway, as the web design community has been saying for years. I looked at each of the HTTP Header Field Definitions and my preference for communicating the CSP version is to add a product token [1] to the User-Agent [2] string. This would add only a few bytes to the U-A and it saves us the trouble of having to go through IETF processes of creating a new request header. I'd much rather have a "\d+;" at the start of the header. Missing implies version 1. Gerv ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy - final call for comments
On 07/04/09 16:28, Sid Stamm wrote: Since the user's entire request header is in the report, any cookies sent with the request header to Angelic get forwarded on. While Be-Evil doesn't actually get forwarded cookies, the cookies are buried in the content of the report that is forwarded under the field. ... (following on from previous message) or we need to say that sites with open redirects are already broken, and this is just another symptom, and we should support redirects for the convenience and reduced implementation complexity. Gerv ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy - final call for comments
On 07/04/09 16:28, Sid Stamm wrote: Since the user's entire request header is in the report, any cookies sent with the request header to Angelic get forwarded on. While Be-Evil doesn't actually get forwarded cookies, the cookies are buried in the content of the report that is forwarded under the field. OK. Then we need to spec that redirects are not honoured. Gerv ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy - final call for comments
Brandon Sterne wrote on 4/7/2009 12:02 PM: > I looked at each of the HTTP Header Field Definitions and my preference > for communicating the CSP version is to add a product token [1] to the > User-Agent [2] string. This would add only a few bytes to the U-A and > it saves us the trouble of having to go through IETF processes of > creating a new request header. I agree that creating a request header for just the CSP version is overkill. However, I am concerned that privacy add-ons, proxies, firewalls, etc may strip or replace the User-Agent string. I propose a new request header is created, but instead of one that is specific to CSP, it is something more generic that can be used in the future by similar policy frameworks. For example: Accept-Header: X-Content-Security-Policy version=2 securityLevel=2; X-Application-Boundaries-Enforcer type=browser FWIW, "X-Application-Boundaries-Enforcer" refers to ABE: http://hackademix.net/2008/12/20/introducing-abe/ I originally came up with Accept-Header during a conversation about revising the Cookie specification; it would alert the server that the client understood "version 3" of cookies: Accept-Header: Set-Cookie version=3 So it does have a variety of uses that may make it worth the effort to register and define. - Bil ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy - final call for comments
On 4/7/09 9:08 AM, Brandon Sterne wrote: >> Have we decided that there's a risk with all inline CSS style, or can we >> define and enforce a large safe subset of the language? Making people >> move their JS to external files is one thing, making them move all the >> style as well is yet another. > > Since style is a vector for JavaScript, via XBL, it needs to be subject > to the same restrictions. Actually, my reasoning is wrong here. Style is no longer a vector for script under CSP because we added the restriction that "XBL bindings must come from chrome: or resource: URIs" for precisely this reason. The other reason to make inline CSS subject to the style-src directive (which I didn't state before because it didn't seem as strong a point) is increased consistency in the model. It seems inconsistent to offer controls on where style can come from if the restriction can be bypassed by injecting CSS directly into the document. Granted, injected CSS poses a much, much lower risk than injected script, but there is still the issue of page defacement, etc. I don't think the no-inline-style requirement is too punitive, though, as sites can still use normal CSS selectors and apply their styles from external, white-listed stylesheets. Sorry for the confusion. -Brandon ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy - final call for comments
On 4/7/09 4:07 AM, Gervase Markham wrote: > I much prefer forwardly-compatible designs to version numbers. I think > the current design is forwardly-compatible, as long as we maintain a > well-signposted public page listing which category all sorts of request > fall into, and add new request types well before they get implemented by > anyone. > > For example, if a <3dvideo> tag, for which you needed red-blue glasses, > made it into a draft HTML5 spec, we would decide and say loudly that > this was included in "media-src" well before anyone actually implemented > it. > > Can you suggest a scenario in which version numbers would help? I think the case for including a version number goes something like this (and strong advocates, please chime in if I miss something): 1. Bugs may be present in the CSP design which require future compatibility breakage. These obviously cannot be foreseen and, though we desire it, we can't guarantee forward compatibility. 2. New types of content (per your example) or new web APIs may be added in the future which don't shoehorn nicely into one of our current policy buckets. If we have to add another policy directive in the future, then it will violate the policy syntax in older versions which will cause them to fail closed (according to the current design). 3. We arguably want to have a pref for users to turn off CSP (for testing or otherwise). It would be useful to have the version number available as a means to communicate to the site that, even though the client supports CSP by default, CSP has been disabled on this client. I looked at each of the HTTP Header Field Definitions and my preference for communicating the CSP version is to add a product token [1] to the User-Agent [2] string. This would add only a few bytes to the U-A and it saves us the trouble of having to go through IETF processes of creating a new request header. Thoughts? -Brandon [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.8 [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.43 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy - final call for comments
Gervase Markham wrote on 4/7/2009 6:07 AM: > On 07/04/09 07:36, Daniel Veditz wrote: >> Maybe this does point out the need for some kind of version number in >> the header, so future browsers can take appropriate action when >> encountering an old header. For example, assuming "none" for any newly >> added types. > > I much prefer forwardly-compatible designs to version numbers. It has to work both ways; old CSP clients need to be able to parse new CSP rules that are unknown to them and new CSP clients need to be able to parse old CSP rules. Where it will become a challenge is anytime something implicit has its meaning changed (e.g. the default is "x" in CSPv1 and "y" in CSPv2). - Bil ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy - final call for comments
On 4/6/09 11:36 PM, Daniel Veditz wrote: > "allow" is not mandatory, but if missing it's assumed to be "allow > none". If you explicitly specify the whitelisted hosts for each type of > load you might not need or want a global fallback which could only be > used to sneak through types you hadn't thought about. Future browser > features, for instance. Not according to our proposed spec: https://wiki.mozilla.org/Security/CSP/Spec#Directives http://people.mozilla.org/~bsterne/content-security-policy/details.html#allow See comments from me and Sid from yesterday explaining why allow is required. I somewhat agree with the spirit of Dan's comment. If allow is not specified, then the _effect_ is to allow none, because the policy is invalid and CSP will fail closed. However, strictly speaking, we don't assume allow none if it isn't specified. We will treat that as invalid policy, logging an error, and not loading any of the content types. By falling back to "allow none" when invalid policy is sent, websites will know right away that their pages are broken because no content, other than textual elements will load. This is a more secure option than failing open and having websites potentially believe their users are protected. -Brandon ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy - final call for comments
On 4/7/09 4:25 AM, Gervase Markham wrote: > What's the story on inline
Re: Content Security Policy - final call for comments
On 4/7/09 4:01 AM, Gervase Markham wrote:
Surely not? If Site Angelic redirects to Site Be-Evil, We don't send
Angelic's cookies to Be-Evil, do we? Or have I missed something? You may
need to describe the attack scenario in more detail for my small brain.
Since the user's entire request header is in the report, any cookies
sent with the request header to Angelic get forwarded on. While Be-Evil
doesn't actually get forwarded cookies, the cookies are buried in the
content of the report that is forwarded under the field.
I think the intention for requiring the allow directive was to force the
policy-writer into writing out the default case to minimize possibility
for false assumptions. I'm not sure though.
Fair enough. As long as the JS console/error report says something
sensible if it's missing.
Of course. Any forgivable but bad policy syntax is going to be spat
into the error console. Terminal ("can't parse") errors will cause CSP
to fail closed ("allow self") and still raise an error.
-Sid
___
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy - final call for comments
On 02/04/09 22:12, Brandon Sterne wrote: We have been working hard lately to finish documenting the Content Security Policy proposal, What's the story on inline
Re: Content Security Policy - final call for comments
On 07/04/09 07:36, Daniel Veditz wrote: Maybe this does point out the need for some kind of version number in the header, so future browsers can take appropriate action when encountering an old header. For example, assuming "none" for any newly added types. I much prefer forwardly-compatible designs to version numbers. I think the current design is forwardly-compatible, as long as we maintain a well-signposted public page listing which category all sorts of request fall into, and add new request types well before they get implemented by anyone. For example, if a <3dvideo> tag, for which you needed red-blue glasses, made it into a draft HTML5 spec, we would decide and say loudly that this was included in "media-src" well before anyone actually implemented it. Can you suggest a scenario in which version numbers would help? Gerv ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy - final call for comments
On 06/04/09 18:12, Sid Stamm wrote: Personally, I don't like the idea of honoring redirects for logging... if a meta tag can be injected into a page (with a CSP header or not) and the site hosts an open redirect, suddenly cookies can be stolen from all visitors to a site. Surely not? If Site Angelic redirects to Site Be-Evil, We don't send Angelic's cookies to Be-Evil, do we? Or have I missed something? You may need to describe the attack scenario in more detail for my small brain. While it's true that this would be easy to implement, I think we need to set a limit. We don't want to spawn off 100 requests every time a policy is violated. If that happens, attackers could leverage the reporting mechanism in CSP to flood a network with traffic. But are there not easier ways of doing this - injecting tags for 100 images on the target server, for example? Given that the reports are so small, I can't see how anyone would want to use it as a DOS mechanism. We should set a limit. I'm just wondering whether "2" is the most convenient limit. I'm not convinced that widespread use will demand more than two report URIs, and it's not difficult to set up that report URI recipient service to fork copies to multiple other destinations. True. It's not a big deal. I think the intention for requiring the allow directive was to force the policy-writer into writing out the default case to minimize possibility for false assumptions. I'm not sure though. Fair enough. As long as the JS console/error report says something sensible if it's missing. Gerv ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy - final call for comments
* Brandon Sterne: > On Apr 4, 10:39 am, Florian Weimer wrote: >> The policy does not say explicitly what happens to javascript: >> hyperlinks and the on* event handlers. > > http://people.mozilla.org/~bsterne/content-security-policy/details.html#no-inline-script Uhm, I meant to say, it's not in the spec. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy - final call for comments
Gervase Markham wrote: > - "but a declared (unexpanded) policy always has the "allow" directive." > I think you need to make it more clear that "allow" is mandatory. But > what was the logic behind making it so? Why not assume "allow *", which > is what browsers do in the absence of CSP anyway? "allow" is not mandatory, but if missing it's assumed to be "allow none". If you explicitly specify the whitelisted hosts for each type of load you might not need or want a global fallback which could only be used to sneak through types you hadn't thought about. Future browser features, for instance. Maybe this does point out the need for some kind of version number in the header, so future browsers can take appropriate action when encountering an old header. For example, assuming "none" for any newly added types. > - "policy-uri documents must be served with the MIME type > text/content-security-policy to be valid" This probably needs an "x-" > until we've registered it, which we should do before deployment. It's > not a complex process, I hear. Until we get CSP onto a standards track they'd probably want us to use a text/vnd.mozilla.something, and since we'd like other browsers to support this I vote we go for the "x-" for now. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy - final call for comments
Hi, Gerv. Thanks a lot for your comments. I'll address the comments that weren't already covered by Johnathan or Sid, both of whom I agree with. On Apr 6, 3:56 am, Gervase Markham wrote: > Are we expecting to see some or all of this in Firefox 3.5, or Firefox-next? Firefox-next. > - "but a declared (unexpanded) policy always has the "allow" directive." > I think you need to make it more clear that "allow" is mandatory. But > what was the logic behind making it so? Why not assume "allow *", which > is what browsers do in the absence of CSP anyway? Sid did address this one, but I want to be clear in the rationale. Once we see the Content Security Policy header (or meta tag), we want to force sites to be explicit about what they are allowing. Yes, "allow *" is the default browser behavior without CSP presently, but we want to avoid cases where sites assume the default behavior of CSP is more restrictive than it actually is. I could envision, for example, a site presuming that "allow none" or "allow self" was the default, and that additional policy could be specified from there. If a site really wants to "allow *", then we want them to explicitly state that. > And the other document > http://people.mozilla.org/~bsterne/content-security-policy/details.html: > > - "policy-uri documents must be served with the MIME type > text/content-security-policy to be valid" This probably needs an "x-" > until we've registered it, which we should do before deployment. It's > not a complex process, I hear. That sounds fair. I'll update the document with that change. > - "Hostname, including an optional leading wildcard, e.g. *.mozilla.org" > Does that include foo.bar.baz.mozilla.org? If so, we should say so > explicitly (in both docs). That's true too. I'll make the language more clear. Cheers, Brandon ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy - final call for comments
On 4/6/09 3:56 AM, Gervase Markham wrote: - When might we see the "Refinements" section with the JS/eval changes? Or is that the other document? The content is in the other document, but most likely we'll be moving that to the wiki too (I've linked to the description doc in the mean time). - What happens if a Report-URI encounters a redirect? We should say specifically in the spec what we do, and I think we should honour it. This would allow us to do "all reports must be sent to the same host that served the protected content" while still allowing people to set it up so that the logging server was a separate machine. Personally, I don't like the idea of honoring redirects for logging... if a meta tag can be injected into a page (with a CSP header or not) and the site hosts an open redirect, suddenly cookies can be stolen from all visitors to a site. - Would it not be more flexible, with negligible change in implementation complexity, to make report-uri multi-valued? We have to support multiple values anyway. While it's true that this would be easy to implement, I think we need to set a limit. We don't want to spawn off 100 requests every time a policy is violated. If that happens, attackers could leverage the reporting mechanism in CSP to flood a network with traffic. I'm not convinced that widespread use will demand more than two report URIs, and it's not difficult to set up that report URI recipient service to fork copies to multiple other destinations. - "but a declared (unexpanded) policy always has the "allow" directive." I think you need to make it more clear that "allow" is mandatory. But what was the logic behind making it so? Why not assume "allow *", which is what browsers do in the absence of CSP anyway? I think the intention for requiring the allow directive was to force the policy-writer into writing out the default case to minimize possibility for false assumptions. I'm not sure though. - The formal syntax uses "" but it's undefined in that formal section. Is that intentional? Nope... that's a mistake, should be "". - Should there be a space or other separator in the middle of ""? Indeed. ";" - The Violation Report Sample has: "some_image.png". Given that the directive blocked was a "self" directive, I would expect some_image.png to be on another host, and therefore for a full URI to be provided. (This is vital for trying to find out who is behind the content injection.) What have I missed? You're right, a full URI would be appropriate there. The wiki was actually parsing out the http://evil.com/ part from both references to "some_image.png" and omitting it... weird. Thanks for the comments! -Sid ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy - final call for comments
On 4/6/09 9:17 AM, Johnathan Nightingale wrote: I think "relaxed" is the intent here, within the context of "the most relaxed policy *satisfying both* ... the meta tag and header." So the intersection is more strict than either on its own, but no more strict than that intersection. I agree that the wording is a bit confusing. Yeah, that's correct. I must have been over-caffeinated when I wrote that. Here is the new, hopefully clearer text: "essentially, the browser enforces a policy that is more strict than both the policies specified in the meta tag and header, but only strict enough to correspond to rules in both policies. Any web request that satisfied both policies alone will be accepted by the new policy, but any request rejected by either one or both of the two policies will be rejected." I also put a kind of formal description following it in the wiki. https://wiki.mozilla.org/Security/CSP/Spec#Policy_Refinements_with_a_META_Tag -Sid ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy - final call for comments
On 6-Apr-09, at 6:56 AM, Gervase Markham wrote: - "When both a X-Content-Security-Policy HTTP header and meta tag are present, the intersection of the two policies is enforced; essentially, the browser enforces the most *relaxed* policy satisfying both the policies specified in the meta tag and header." Surely you mean "strict", not "relaxed"? The example seems to show that the resulting policy is more strict than either of the two source policies. I think "relaxed" is the intent here, within the context of "the most relaxed policy *satisfying both* ... the meta tag and header." So the intersection is more strict than either on its own, but no more strict than that intersection. I agree that the wording is a bit confusing. Cheers, 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: Content Security Policy - final call for comments
Hi Brandon, Thanks for your continued hard work on this. Are we expecting to see some or all of this in Firefox 3.5, or Firefox-next? On 02/04/09 22:12, Brandon Sterne wrote: If you have feedback that you would like to share regarding Content Security Policy, please do so ASAP as the window for making changes to the model will soon be closing. Here are some comments on https://wiki.mozilla.org/Security/CSP/Spec. In general, I think it's excellent :-) - When might we see the "Refinements" section with the JS/eval changes? Or is that the other document? - "When both a X-Content-Security-Policy HTTP header and meta tag are present, the intersection of the two policies is enforced; essentially, the browser enforces the most *relaxed* policy satisfying both the policies specified in the meta tag and header." Surely you mean "strict", not "relaxed"? The example seems to show that the resulting policy is more strict than either of the two source policies. - What happens if a Report-URI encounters a redirect? We should say specifically in the spec what we do, and I think we should honour it. This would allow us to do "all reports must be sent to the same host that served the protected content" while still allowing people to set it up so that the logging server was a separate machine. - Would it not be more flexible, with negligible change in implementation complexity, to make report-uri multi-valued? We have to support multiple values anyway. - "but a declared (unexpanded) policy always has the "allow" directive." I think you need to make it more clear that "allow" is mandatory. But what was the logic behind making it so? Why not assume "allow *", which is what browsers do in the absence of CSP anyway? - The formal syntax uses "" but it's undefined in that formal section. Is that intentional? - Should there be a space or other separator in the middle of ""? - The Violation Report Sample has: "some_image.png". Given that the directive blocked was a "self" directive, I would expect some_image.png to be on another host, and therefore for a full URI to be provided. (This is vital for trying to find out who is behind the content injection.) What have I missed? And the other document http://people.mozilla.org/~bsterne/content-security-policy/details.html: - "policy-uri documents must be served with the MIME type text/content-security-policy to be valid" This probably needs an "x-" until we've registered it, which we should do before deployment. It's not a complex process, I hear. - "Hostname, including an optional leading wildcard, e.g. *.mozilla.org" Does that include foo.bar.baz.mozilla.org? If so, we should say so explicitly (in both docs). Again, great work :-) Gerv ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy - final call for comments
On Apr 4, 10:39 am, Florian Weimer wrote: > The policy does not say explicitly what happens to javascript: > hyperlinks and the on* event handlers. http://people.mozilla.org/~bsterne/content-security-policy/details.html#no-inline-script > You shouldn't use an X- header because it's going to stick around and > preventing standardization (see X-Complaints-To on Usenet). I think an X-header makes sense for CSP at this point, since it is not yet standardized. A standards group like W3C's public-webapps is probably the right venue for that conversation to take place. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy - final call for comments
* Brandon Sterne: > We now have a specification document to work from (thanks, Sid!) and > it and other supporting docs can be found on the Mozilla Wiki: > https://wiki.mozilla.org/Security/CSP/Spec The policy does not say explicitly what happens to javascript: hyperlinks and the on* event handlers. You shouldn't use an X- header because it's going to stick around and preventing standardization (see X-Complaints-To on Usenet). ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Content Security Policy - final call for comments
Hello all, We have been working hard lately to finish documenting the Content Security Policy proposal, which we plan to start implementing very soon. For those of you who have followed the progression of CSP, you have seen the model grow quite a bit in complexity. As one thinks through the CSP model, it becomes clear that a certain amount of complexity is in fact necessary for the model to be useful. I have done my best to describe the model and provide justification for the various restrictions here: http://people.mozilla.org/~bsterne/content-security-policy/details.html We now have a specification document to work from (thanks, Sid!) and it and other supporting docs can be found on the Mozilla Wiki: https://wiki.mozilla.org/Security/CSP/Spec If you have feedback that you would like to share regarding Content Security Policy, please do so ASAP as the window for making changes to the model will soon be closing. Cheers, Brandon ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
