IE8 Security Part VI: Beta 2 Update

Now that Beta 2 has released, I want to provide a short update on some of the smaller security changes the team has recently made. I’ve also linked to a great article on the IE8 XSS Filter implementation written by the architect of that feature.

Restricting document.domain

The document.domain property initially returns the fully qualified domain name of the server from which a page is served. The property can be assigned to a domain suffix to allow sharing of pages across frames from different hostnames. For instance, two frames running at app1.example.com and app2.example.com can script against one another if both frames set their document.domain to their common example.com. A frame may not set its domain property to a top-level-domain, nor to a different domain suffix. For instance, app1.example.com cannot set its domain property to .com or microsoft.com. The HTML5 proposal formalizes the algorithm used to determine if a given domain property assignment is permitted, and it specifically requires that the assigned value is a suffix of the current value.

In Internet Explorer 7, the following set of calls would succeed:

// initial document.domain is app1.example.com

document.domain = "app1.example.com" // 1. Domain property set to default value

document.domain = "example.com" // 2. “Loosen†domain

document.domain = "app1.example.com" // 3. “Tighten†domain

In Internet Explorer 8 and other browsers, the 3rd assignment will throw an exception, because app1.example.com is not a suffix of the then-current value, example.com.

Put simply, once you’ve loosened document.domain, you cannot tighten it.

Web Applications that need to interact with data from other domains may wish to consider using the postMessage() or XDomainRequest APIs rather than adjusting the document.domain property.

Restricting Frame-Targeting

HTML5 also specifies the circumstances in which one frame is permitted to use the targetname parameter of a window.open() call to navigate another named frame or window.

The rules are meant to help prevent a window injection vulnerability. In a window injection attack, a malicious website in one browser frame attempts to “hijack†a frame or popup owned by a trusted webpage.

For instance, consider the scenario where http://contoso.com opens a popup window with the name helpPage.

window.open("helpTopic.htm", "helpPage", "height=200,width=400")

If another page at http://evil.example.com attempts to hijack this window, like so:

window.open("spoof.htm", "helpPage", "height=200,width=400")

…instead of navigating the helpPage window owned by Contoso.com, spoof.htm will instead open in a new browser window. While Internet Explorer 7 and 8 always show an address bar on every window, this new restriction makes window injection spoofs even less convincing.

MIME-Handling: Sniffing Opt-Out

As discussed in Part V of this blog series, Internet Explorer’s MIME-sniffing capabilities can lead to security problems for servers hosting untrusted content. At that time, we announced a new Content-Type attribute (named “authoritativeâ€) which could be used to disable MIME-sniffing for a particular HTTP response.

Over the past two months, we’ve received significant community feedback that using a new attribute on the Content-Type header would create a deployment headache for server operators. To that end, we have converted this option into a full-fledged HTTP response header. Sending the new X-Content-Type-Options response header with the value nosniff will prevent Internet Explorer from MIME-sniffing a response away from the declared content-type.

For example, given the following HTTP-response:

HTTP/1.1 200 OK

Content-Length: 108

Date: Thu, 26 Jun 2008 22:06:28 GMT

Content-Type: text/plain

X-Content-Type-Options: nosniff

This page renders as HTML source code (text) in IE8.

In IE7, the text is interpreted as HTML:

In IE8, the page is rendered in plaintext:

Sites hosting untrusted content can use the X-Content-Type-Options: nosniff header to ensure that text/plain files are not sniffed to anything else.

XSS Attack Surface Reduction: CSS Expressions Disabled IE8 Standards Mode

Also known as “Dynamic Properties,†CSS expressions are a proprietary extension to CSS that carry a high performance cost. CSS Expressions are also commonly used by attackers to evade server-side XSS Filters.

As of Beta 2, CSS expressions are not supported in IE8 Standards Mode. They are still supported in IE7 Strict and Quirks mode for backward compatibility. While the IE8 XSS Filter can block attempts to reflect CSS Expressions as part of an XSS attack, blocking them in IE8 Standards Mode brings a performance benefit, improves standards-compliance, and acts as an attack surface reduction against script injection attacks.

Deep Dive on the IE8 XSS Filter

David Ross, architect of the IE8 XSS Filter has published a technical article on the architectural and implementation details of the XSS Filter over on the Secure Windows Initiative blog. If you’re interested in the nitty-gritty details of how the XSS Filter operates, please take a look.

Thanks for reading!

Eric Lawrence

Program Manager

Internet Explorer Security

More...