Internet Explorer 8's XSS Filter examined

Internet Explorer 8 is set to introduce an integrated XSS Filter with its release.

Another intriguing decision is to allow requests in the local Intranet zone to happily be made without filtering. If the filter hasn't stopped the initial request, it means that the JavaScript port scanners and network mappers that have been developed in the last 18 months will continue to have a viable means of functioning. It could be argued that stopping this is outside of the scope of a basic XSS filter, but it shows that it is possible to launch attacks against resources that might otherwise be considered in a 'safer' Internet Explorer zone from a remote site.

Yet another interesting aspect is the decision to use a combination of heuristics and signature matching to identify XSS attacks, with the heuristic methods being used to compile and add to the signature database in use. If designed correctly, it could allow users to share and modify their signature database to include defence against XSS attack methods they haven't already encountered. Microsoft could use reports from users to compile a core signature collection that is then updated with the monthly security patches, much as the Malicious Software Removal Tool is.

Microsoft's efforts are to be commended, however with reality being somewhat hostile, Internet Explorer users should not fall into the trap of thinking that the in-browser XSS filter will protect them against any and all potential issues, much as they shouldn't with the many and varied in-browser anti-phishing initiatives that are in use. This is something that is acknowledged in the SVRD post, both in terms of the type of XSS attack to be targeted (basic reflected XSS) and in terms of what will not be protected against (such as the many other XSS methods).

If you take the approach that it is a backstop against accidental user mistakes, then the filter will have a long and useful life and should form part of an integrated defence posture. To achieve this, the development team need to minimise the deviation from the desired design conditions and ensure that the filter doesn't annoy users to the point that they will willingly turn it off to regain normal browser or site performance.

If the development team can deliver a viable solution, it is something that other browser and rendering engine developers should pay attention to and consider implementing their own similar solutions.

Join the newsletter!

Or

Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

Tags filterXSSIE 8

More about Adobe SystemsMicrosoftMozilla

Show Comments
[]