3 ms·

There are a lot of good things there but the author seems to be looking at it like "there's a bunch more headers on G+ ITS BETTER!" Unfortunately it's not true

by zobzu 15y ago

There are a lot of good things there but the author seems to be looking at it like "there's a bunch more headers on G+ ITS BETTER!" Unfortunately it's not true. For instance, G+ does not use X-Content-Security-Policy (https://wiki.mozilla.org/Security/CSP/Specification https://wiki.mozilla.org/Security/CSP/Specification) and uses X-XSS-Protection instead, which is a solution not exactly designed properly. (Noscript is a slightly better implementation, but since its client side, no dice) You can also check this at Wekbit: https://bugs.webkit.org/buglist.cgi?keywords=XSSAuditor&resolution=--- https://bugs.webkit.org/buglist.cgi?keywords=XSSAuditor&... Many G website just disable that filter afaik because sometimes it can be misused by the attacker. I suppose that Chrome will eventually support X-Content-Security-Policy or something similar and then G sites will switch to that.

mike-cardwell 15y ago
Current versions of Chrome support CSP, but by using the X-WebKit-CSP header. Once they are happy with the implementation, they will use the correctly named header.
justinschuh 15y ago
You seem to be confused here. CSP and the XSS auditor are not mutually exclusive; you can certainly use both and one can cover areas missed by the other. Also, in terms of market share the XSS auditor is going to be supported by a bigger user base than CSP. It's also important to note that the XSS auditor is disabled on other Google sites primarily because it hasn't been tested for compatibility--not because it can be misused by an attacker. As for CSP support in Chrome, it's currently available if you set a vendor-specific header. (That's the normal way to handle an experimental standard that's still in flux.) My personal opinion on CSP is that it's a bit of an overly complicated mess. We didn't plan to implement it in Chrome/WebKit until very recently, mainly because Mozilla got some major sites on board. In the end, we decided users would be better served by CSP (warts and all) than by any attempts at yet another standard.

by zobzu 15y ago

mike-cardwell 15y ago

Current versions of Chrome support CSP, but by using the X-WebKit-CSP header. Once they are happy with the implementation, they will use the correctly named header.

justinschuh 15y ago

You seem to be confused here. CSP and the XSS auditor are not mutually exclusive; you can certainly use both and one can cover areas missed by the other. Also, in terms of market share the XSS auditor is going to be supported by a bigger user base than CSP. It's also important to note that the XSS auditor is disabled on other Google sites primarily because it hasn't been tested for compatibility--not because it can be misused by an attacker. As for CSP support in Chrome, it's currently available if you set a vendor-specific header. (That's the normal way to handle an experimental standard that's still in flux.) My personal opinion on CSP is that it's a bit of an overly complicated mess. We didn't plan to implement it in Chrome/WebKit until very recently, mainly because Mozilla got some major sites on board. In the end, we decided users would be better served by CSP (warts and all) than by any attempts at yet another standard.