Microsoft to fix further vulnerabilities in IE 8 XSS filter

When a security feature regularly generates insecurity, it might be time to ask whether it might not be better to remove it from the product, or even to rethink the whole concept. However, that isn't the Microsoft way – a third update for Internet Explorer 8's cross-site scripting (XSS) filter will aim to fix yet another vulnerability, one which actually makes web sites that weren't vulnerable, vulnerable. Attackers can exploit the problem to inject JavaScript into HTML pages and execute it with the privileges of the normally visible web page.

The presence of vulnerabilities in Internet Explorer 8' XSS filter was first disclosed back in November. Microsoft has already released two updates, MS10-002 in January and MS10-018 in March, which fix some of these vulnerabilities. A further update is now planned for June to fix the SCRIPT tag-related vulnerabilities described at last week's Black Hat Europe conference. David Ross from Microsoft nonetheless remains of the opinion that it is important for browsers to have XSS filter functionality. He believes that protection against standard XSS attacks in most cases outweighs the potential risk from bugs.

In contrast to popular Firefox plug-in NoScript, Internet Explorer 8's XSS blocker filters server responses, rather than client requests, for suspicious code (reflective XSS), and amends them where appropriate. This can be exploited by attackers to modify server responses in order to inject code. The attacker does need some degree of control – such as that provided by social networking sites, forums and wikis – over the content of the page being visited by the victim. The example cited in the Black Hat presentation is, unsurprisingly, Facebook. Google and Google services are also affected. Google disables Internet Explorer 8's XSS blocker by sending the header X-XSS-Protection: 0. Since the March update, Internet Explorer 8 also supports the X-XSS-Protection: 1; mode=block header. This tells the browser that, instead of modifying server responses, if in doubt it should block all content from the site.

Google's Chrome 4 also contains an experimental cross-site scripting blocker known as XSS Auditor. It checks whether any JavaScript, returned when generating a vulnerable web page, was included in the request. If it was, you're probably staring down the barrel of a reflective XSS attack involving a manipulated link and the browser declines to execute the script. Chrome (or WebKit) also supports X-XSS headers; block mode is not yet supported, but is scheduled for inclusion in a future version.

See also:

• Security feature of Internet Explorer 8 unsafe, a report from The H.

(crve)