Paul twitted a former entry of this blog about the IE8 XSS filter, subsequently attracting reactions on this otherwise very quiet blog :-).
As the post in question was a typical trollish rant of me, in the usual mood "I lost three hours of work because of something, so this thing must be crap and I must get it out of my system", it wasn't specially informative neither trying to make a point, but rather just "bash the damn browser"! :-)
As David Ross was kind enough to comment on it, let's try to fix this with a new post, in order to re-orient the discussion to something more productive.
Technically that is:
- trolls and gratuitous bashing may be expressed on the other blog entry
- productive comments may go here
The opt-out approach sounds bad
The first thing I strongly dislike about the XSS-Filter is that you need to opt-out of it, not opt-in to get it.
The opt-out approach sounds badMicrosoft has in the past introduced non-standard "security" features - I'm thinking specifically about the httponly hack (to prevent a cookie from being accessed in javascript). Whatever the quality or interest of this trick, it was an "opt-in" feature - the developer had to specifically craft http headers to use it.
The opt-out approach means the developer has to first figure out what is causing disruption. Then find the way to fix it. Then change its production code to opt-out from it. This is not actually a new feature you can use, this is (to me) a new burden you need to be sure to workaround (assuming you don't want it, of course).
I don't think this is a nice approach to developers - not to mention this do breaks previously working stuff (whether or not innovation on the web should break backward compatibility is a whole debate on its own, but it's worth noting that Microsoft usually do preserve it).
Put otherwise, I don't want to get through browsers changelogs at each version to ensure they are not putting in something new that will disrupt expected behavior (because I'm a developer, hence I'm lazy, and this is extra-work with no benefit, and I'm not willing to do it :-)).
A few years ago, I was shocked in the same way when Microsoft removed from IE the ability to specify a username and password in a url (eg: http://john:secret@somehost/).
I don't think the question should be: "is my new feature good or not?", but rather, "do I violate established standards with it?", and "do I break previously working legit things with it?". The features that fall in the "yes" category should IMHO be opt-ins.
This feature may not help developers
XSS result from coding errors. Hiding coding errors, or mitigating them in a way that let newbies developers think thus errors are not (so) bad is definitely not helping them.Maybe I'm old school, but well, that's my past: I learned things the hard way. I got hacked. I got rooted. I made coding and administration mistakes. Maybe not all of them, but a good number of them :-). This is how you learn IMHO.
To me, it sounds like this filter will actually trick people into thinking that sloppy-code is not a risk. Don't fix the problem, have another piece of software filter things out elsewhere. Looks a bit like the "windows need a firewall" story. You need a firewall because you're exposing softwares with security defects on open ports. And people do sloppy-code such softwares because they don't care, because they assume there must be a firewall. So, in the end, I have to explain to mom that she is faulty for not having a firewall in the first place. Repeat after me: users have to take measures to protect themselves. This is normal. Don't dare questioning why. Protect yourself. :-)
This feature may not protect users
It may protect IE8 users - although I do think a side-effect of the above point will be to lower web developers' care level about XSS, hence multiplying vector attacks.But it definitely won't help protecting people who don't use IE8, actually, it will harm these users, by encouraging web-devs to not care about XSS.
Probably one could state that patching other User Agents is not Microsoft problem, and that others do as well provide extra "security" features. But IMHO there is a distinction between putting out a feature that simply better protects your users, and a feature that does (directly or not) harm users of your concurrents.
This feature seems more like a marketing move
I wouldn't be too surprised if this would be advertised as part of the "IE8 is more secure than X because..." campaign.Indirectly, I wouldn't be surprised as well if people who have problems on vulnerable sites with browser X get answered by developers that they should use IE8 to be safe (which is not an accurate description of the issue)... contributing to that same marketing effort.
Conclusion
Well, I don't mean to be harsh for the pleasure of it. Please note I'm not working for a (concurrent) browser maker (at Zoomorama, we are so selfish that we decided to write our own browser rendering our own markup language :-)).Please finally note I don't have hard feelings on the IE team (past the headaches their damn browser gave me when I was young and doing web stuff! :-))
And yes, some points have been made defending this filter. Notably, that web-developers who don't care fixing XSS issues won't care disabling the filter, resulting in a real security enhancement for users on existing sloppy-anyhow websites.
All-in-all, any security effort on the web should be applauded, and I'm rather sure that the boys who developed it actually meant to go that way (yeah, I poked them in the previous post - my wicked humor :-)).
But still, I'm egoistically concerned about what's good or bad for me or my team as a developer :-), then about what's good or bad for the future of the web.
And despite the proponents' points, I still have a hard time figuring out how that feature would qualify as "good" in either category, for the reasons exposed.
In the hope this post helped somehow (at least in being better than the previous one), peace.
Comments
#1
David Ross
Saturday, November 7 2009, 02:31
Olivier, I think these are reasonable arguments and not easily dismissed. Here’s what I’d say in response. In some sense, your viewpoint may be considered an indictment of all proactive security technologies, including anti-virus. That is, if AV software is running on your computer and a desktop application meets some criteria, there’s a possibility that the desktop application will not behave as intended. In some cases this can be a severe issue, for example the AV software might delete the application binary. By and large, users and developers have come to accept the risks because they see value in AV. This is certainly not guaranteed though -- AV needs to live up to its end of the bargain.
Ideally, I’d like to live in a world where AV software is unnecessary. But we live in the modern world where sophisticated attacks require advanced defenses. I’m sure you’d agree that if the XSS Filter blocks a real attack then this is a clear win. Likewise, I would agree that if the filter’s behavior breaks an otherwise working web page, that’s a loss for everyone – not only the developers who need to go work around the issues, but also the users who are affected, and ultimately Microsoft.
The burden is on us to get the balance right, and we do not take this responsibility lightly. FWIW, as you can see, the first of our three design goals as stated in the Architecture / Implementation overview is “The XSS Filter must be compatible.”
Based on the data we have, we feel pretty good about where we are now ~8 months after IE8 RTM. Going forward, we are able to measure our compatibility on an ongoing basis to ensure high quality future releases. Nevertheless, we’re constantly on the lookout for problems. If you are seeing compatibility issues pop up that we may not be aware of, please get in touch (http://blogs.msdn.com/dross/contact...).
I’d also point out that we’ve been careful to dispel any notion that developers can now become lazy and avoid fixing legitimate XSS bugs because of IE’s filter. At a minimum, older supported versions of IE and competing browsers do not benefit from the IE8 XSS Filter. And the IE8 XSS Filter is not an XSS panacea. (For example, we do not make any attempt to mitigate Persistent (“Type-2”) XSS.)
From the MSDN documentation you referenced in the previous post:
“However, this feature should only be disabled with the recognition that it will disable defense-in-depth protection for Cross-Site Scripting attacks in Internet Explorer. Best practices should be put in place to eliminate Cross-Site Scripting at the server regardless of if the XSS Filter is enabled or explicitly disabled at the client.”
Finally, to answer the question of the filter’s overall worth, I’d just re-state from the design doc:
“In summary, the XSS Filter will prove its worth by raising the bar and mitigating the types of XSS most commonly found across the web today, by default, for users of Internet Explorer 8.”
I’d argue that an opt-in mitigation would not address the problem for the majority of users, who just want security out of the box.
(One final point I’d like to make… Do not draw _too_ much of a comparison between anti-virus software and the XSS Filter. The XSS Filter is not looking for identified attacks and attempting to block them. Rather it’s targeting specific XSS attack vectors and authoritatively shutting them down, modulo any bugs in our implementation.)
We’ve recently seen various on-by-default and off-by-default technologies for client-side XSS mitigation emerge. So I think this is a very healthy, timely discussion!
Dave
#2
dmp
Monday, November 9 2009, 17:37
> "In some sense, your viewpoint may be considered an indictment of all proactive security technologies"
Well... to some extent. Back to the anti-virus example, I would rather support ASLR and No eXecute than antivirus softwares. Both approaches are proactive I think. The latter tries to mitigate consequences of intrinsic system flaws, while the former tries to address them. So, I would rather say that my viewpoint may be considered an indictment of security technologies whose purpose is to alleviate symptoms rather than fix the actual problem. Please correct me if I'm wrong (as I'm not a security guru), but it seems to me that ASLR *and* proper privileges separation at the OS level fix most of the virus threat - up to the point it is sane to live without an AV software on such a platform. Either way, and as you emphasized, the parallel with viruses is not that useful a comparison here.
> "The burden is on us to get the balance right, and we do not take this responsibility lightly.[snip]"
I certainly am glad to hear you take this responsibility at heart, and that you do mean to do well - not that I doubted it ;)
> "I’d argue that an opt-in mitigation would not address the problem for the majority of users, who just want security out of the box."
Possibly true, yes.
> "I’d also point out that we’ve been careful to dispel any notion that developers can now become lazy and avoid fixing legitimate XSS bugs because of IE’s filter."
Assuming that documentation will receive the attention it deserves...
Anyhow, our disagreement here essentially is a matter of beliefs - in what would be the correct approach to solve these problems.
Digging a bit deeper, it seems to me that:
* websites that don't care to fix their XSS issues when pointed out are likely unmaintained. I don't think that unmaintained websites are likely to attract a vast number of users, or be critical in any way (eg: data sensitive). Furthermore, such websites certainly have way more flaws than just non-persistent XSS...
* on the other hand, websites that do care are likely to fix them timely, just like regular softwares are patched
I guess the filter will do its work, in some cases - question being: how many cases? Time will tell, and I would love to see some stats in a year from now - actually, I would love to be proven wrong about it ;)
Now, what would *I* do to help fight XSS?
* Put the focus on developers, and provide them dev-tools, bundled with browsers, that do XSS auditing/reporting (yes, the XSS filter would be a good one), with big fat warnings
* lobby server-side platforms developers so that mentalities change and they *by default* provide user input sanitation (not only for XSS injections)
Probably these will not be as immediately "effective" (eg: provide visible results) as the XSS filter, but in my opinion, they are the way to go to actually fix things.
</random_thoughts>
Cheers.