Security

I appreciate your efforts to bolster security on the web, but this is an over-reaction. Has anyone conducted any decent risk analysis of XSS attacks? Involving hard estimates of probabilities and utilities (or at least economic costs)? Has anyone compared these costs to breaches of security via other means? (i.e. viruses, malware, browser holes, server exploits, psychological tricks) Would the costs be within even an order of magnitude? Would the costs be within even several orders of magnitude?

Please answer these questions before you consider radically changing the culture of the web.

As far as I can tell, all public website XSS problems can be solved very simply by fixing 3rd party cookie security rights (a la web fonts, XHR, etc.) and using sandboxes. The fact that cross-site cookies today aren’t treated with the same gravity as cross-site XHR et al. (by all browser makers) is an absolute scandal.

This proposal is an inappropriate response to the problem: it is 10 years in jail for littering. Please — *please* — consider what you are doing very carefully before proceeding.

 #2:

@Brandon: I appreciate CSP is an opt-in security technique (mandatory would be lunacy) but unless I’m much mistaken, you intend it to eventually be used by all major sites. Otherwise, why go to such efforts? If all major sites use it, it will have to be taught in colleges and universities as preferred web-programming practice. Hence why it will change the current culture.

"The severity of the XSS problem in the wild … [is] open to interpretation by individual sites."

Ah, well, I don’t agree; the severity of the XSS problem is objective. It may not be easy to measure the severity (in terms of economic cost or, more accurately, social harm), but it is nonetheless objective. Are there any studies of the long-term economic costs of XSS attacks as compared to viruses or, say, bad web design?

 #3:

@Daniel: “[Disabled 3rd party cookies] was no protection from any of the XSS attacks.”

Really? I hope you’ll understand if I have my doubts.

You’d at least agree that if someone is logged into their favourite pet store website, an evil 3rd party website can execute privileged actions on the pet store site unless the pet store site has taken appropriate security measures on the server. This wouldn’t be a problem if 3rd party cookie rights were handled properly (that is, as per cross-site XHR and fonts).

I think we need to be clear about which XSS security issues we are dealing with:

• HTML injection via GET or POST parameters: These can’t automatically be blocked because you can’t automatically tell the valid from invalid uses of HTML in submitted parameters. Yes, HTML in a GET parameter is unusual today, but it might not always be that way. JSON in a GET parameter was unusual once, too. And page injections here aren’t the real concern (sandboxes can do the protection) — the big worry is injection on the server (e.g. SQL injection, command line injection, out of bounds values, etc.)
• User submissions and user pages (ebay, facebook, webmail, etc.): Random-boundary sandboxes. Enough said. Also, the style tag should only apply locally within its parent node! (It’s preposterous that style tags are hoisted to document level.) Imagine how simple life would be for the GMail developers if they could simply wrap each email in a conversation in its own sandbox?
• Identity theft: As I described before, this can be solved by doing 3rd party cookie security properly. Intranets are different, but that’s just because privileges are identified differently (but don’t worry, the problem can still be solved). Identity can also be stolen when cookie authentication is used in conjunction with user submissions — but in those cases, what fixes the problem? Sandboxes.

Again, the moral of the story is all XSS attacks can be vitiated by proper 3rd party cookie security and sandboxes (very important). In fact, CSP is just a very extreme and very inflexible form of sandbox!