So...
Does anyone actually think most web developers will ever bother with this? I mean, half of them can't be arsed to validate their code, let alone make use of an opt-in security feature like this.
The Mozilla Foundation has unveiled an early version of its Firefox browser that it says could virtually eliminate one of the most common attack forms now menacing the web. It implements an inchoate technology the foundation calls CSP, short for the Content Security Policy specification. It allows web developers to embed a …
Though superficially appealing, its hard to see how this would be something web sites could depend upon as a substitute for adequate security measures.
It looks more like something that might protect users from a web site that has *already* been compromised by an XSS attack.
In a sense a message from the web site admin saying "Hi! I couldn't be bothered to write code to protect you from XSS, assume the user generated content of my web site has probably been hacked. Hope your browser covers your arse, because I didn't cover mine. Good luck, you're on your own".
But its not a solution for web sites.
The big problem is that the web's inherent security policy is ALLOW by default. This isn't so much a problem of the web developers (who are only human and can't be expected to find every last nuance malware authors create) as it is a flaw in the overall nature of the Web. CSP, which essentially forces web policy into a whitelist rather than a blacklist, could mark an important step towards moving towards a DENY by default (otherwise known as DTA--Don't Trust Anyone) policy. Deny By Default is much more likely to prevent novel (ie. zero-day) exploits from causing havoc.
This is a nice idea but will probably be ignored by authors of sites which are the most vulnerable to XSS: those who allow javascript widgets to be embedded. Such widgets *rely* on scripts being able to run from different domains, so won't be able to supply a whitelist... hmm, unless the tags which list the safe domains can be scripted into the HTML at runtime :-p
Lazy coders in and of themselves aren't the problem. The problem is that learning resources don't teach all the concepts of security required to mitigate the vast majority of possible attacks. College classes on web design, coding tutorials, etc, just don't take the time to explain how every single attack against the application could work. Allow by Default only exacerbates this issue, because now you have developers who aren't entirely aware of what their application can be made to do, and the application is going to do it by default now.
By Adam Azarchs Posted Saturday 3rd October 2009 19:32 GMT
"Let's invent even more non-standard tags and fragment the browser design space further! This is exactly what the world needs now!"
It seems you missed something:
"Mozilla hopes it will become an open standard and is already shepherding it through the World Wide Web Consortium."
That doesn't look like an attempt to fragment or use non-standard tags. Just the opposite.
You are correct to the part that you say that Allow By Default exacerbates the problem, no, it doesn't the first part of your comment is correct, poor education, lack of awareness and lazy/malicious coding are the problem.
Ok, now I don't expect perfection, and to be realistic Allow By Default would be the optimum setting for an ideal world, unfortunately that doesn't exist. So maybe a compromise should be made, perhaps the removal of Allow By Default, to be replaced with At Your Own Risk.
But that doesn't detract from the fact that the fault lies elsewhere than with the browsers.
Well, assuming the thing does indeed work well (to be seen?), I can see a big advantage to it in situations such as:
- bank site developers are lazy and/or uninformed and don't use this technology;
- bank site users become victims of XSS;
- bank is then easily shown to be negligent in their security practices, and will be held responsible for losses.
If this indeed occurs as I naively see, then I guess banks (and other sites with sensitive content) would definitely have quite an amount of incentive to keep their devs' practices good at work under penalty of sacking and all that.
Or not.
Protecting against these types of attacks on the client side is all well and good, but you are taking the wrong approach.
If the developer is going to add "protect me" into the page headers, then why are they not using proper input filtering? Put the effort into fixing the problem instead. Not relying on the user having a hand-holding browser. Any user with a browser that does not support this feature is still going to be susceptible.
Nice try, but your doing it wrong.