Cатсн²² (in)sесuяitу / ChrisJohnRiley

Universal XSS via IE8’s XSS Filters (David Lindsay & Eduardo Vela Nava)

Abstract (source: Blackhat.com)

Internet Explorer 8 has built in cross-site scripting (XSS) detection and prevention filters. We will explore the details of how the filters detect attacks, the neutering method, and discuss the filters’ general strengths and weaknesses. We will demonstrate several ways in which the filters can be abused (not just bypassed) in order to enable XSS on sites that would not otherwise be vulnerable. We will then show how this vulnerability makes most every major website vulnerable to XSS in affected versions of Internet Explorer 8.

Talk Abstract –> Universal XSS via IE8s XSS Filters

Speaker Bio –> David Lindsay, Eduardo Vela Nava

The sordid tale of a wayward hash sign

Client-side XSS Filtering

• XSS is extremely common.
• Reflective XSS is detectable in the browser

Microsoft decided to implement an XSS filter in Internet Explorer 8 in an attempt to help users protect against this threat. Firefox has the NoScript plugin that performs the same kind of functionality. Chrome is also working on a similar feature.

Microsoft XSS design goals

…intended to mitigate reflected / “Type-1” XSS vulnerabilities in a way that does not “break the web.

— David Ross

• compatible
• secure
• performance

Detection process (3 step process)

• Examine all outbound requests for XSS patterns using heuristic filters
• If heuristic matches outgoing HTTP request then create a dynamic signature
• If signature matches HTTP response then neuter the response

Heuristics

Matches again GET/POST requests

23 Regular expressions (see http://p42.us/ie8xss/filters02.txt)

Dynamic Signatures

• One created for each matching heuristic
• Matches against inbound responses
• Blacklisting regular expressions
• Account for server side modifications

Neutering Process

• No user interaction, just notify the user
• Replace the flagged character(s) with the hash symbol: #
• Render the altered response

Heuristic Breakdown

Check of fixed strings such as javascript: vbscript, as well as HTML tags/attributes and JavaScript strings.

Filter Abuse – Attacks made possible because of the filters

Simple:

When an attack is detected, altering the response before rendering can have unintended consequences.

Example – An attacker supplies a bogus GET parameter of &foo=

This will trigger the XSS protection and disable any <script> tag on the target will be disabled

How useful is this ?

• Disable client side security features
  • Block Framebusters
  • Escape Facebook’s CSS Sandbox
  • Any other JS based security controls

Simple 2:

An attacker inserts a string such as // <![CDATA[
var foo='<img src=x:x onerror=alert(0)>’;
// ]]>. When the filter neuters the //

unfiltered: // <![CDATA[
var foo='<img src=x:x onerror=alert(0)>’;
// ]]>

filtered: var foo='<img src=x:x onerror=alert(0)>’

Universal XSS Intro

Equals signs are neutered by the filter (using a RegEx).

Almost any equals sign could be neutered if a suitable trigger string was inserted

Example: &fake=’>anything.anything=

<img alt=”x onload=alert(0) y” src=”mars.png”> could then become

The browser would then interpret the previously inactive onload condition and create an XSS condition.

Crafting an attack

• Identify a persistent injection
  • confirm and insert a suitable XSS string
• View source to identify a trigger string
  • work backwards from target = sign
• Create vulnerable URL to target page
  • append trigger string using a fake GET parameter

Moving Forward

The Fix from Microsoft –> Stop neutering equals signs, and start neutering other characters instead

These new filters don’t seem to open up another attack vector… but this isn’t 100%

Other mitigations:

• Use another browser
• Disable XSS protection in IE (not recommended)
• Only earlier versions of IE8 are affected… so patch

Should you disable filters ?

No… benefits outweigh the risks.

Server-side:

• Filter user input
• Site-Wide anti-CSRF tokens
• Make use of the response header opt-out

X-XSS-Protection

• 0 – turns off the filter completely
• 1; mode=block – turns on the filter in block mode
  • Not fully supported in all browsers
  • Doesn’t filter, prevents page from loading

Other browsers:

Firefox

• Only add-ons for XSS protection
• NoScript
• NoXSS (not recommended)

Webkit is developing XSSAuditor

• Filter based
• Sits between HTML parser and JS engine
• Respects same control headers as IE
• –enable-xss-auditor to enable

Additional Links

• Slides – Blackhat Europe 2010
• IE8 XSS Filter List
• Cigital
• Sirdarckat.net
• – Our Favorite XSS Filters and how to Attack them
• Blackhat USA 2009 – Our Favorite XSS Filters and How to Attack Them (PDF)

For more information please see the Blackhat Europe website