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
