> 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. ;)
> 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.
> 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.
>> 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.
> 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.
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.
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? :-)
> 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 <video>". "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?
> 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 <video>". "I support > HTML5". Etc. I think the slippery slope argument has validity here.
The support of <video> or HTML5 by a client does not have the same security implications as the support of CSP. If a client does not support <video> and a site serves it to them, there is no risk to the client, which can passively ignore the <video> 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.
On Apr 2, 5:12 pm, Brandon Sterne <bste...@mozilla.com> 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?
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.
> 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.
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 <meta> 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 :-)
> 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.
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.
> 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 <meta> 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.
