Secure Coding with Internet Explorer 8 Beta 2

The Internet Explorer team has made significant investments to ensure that Internet Explorer 8 Beta 2 is the most secure version to date.

Many of these improvements (like the SmartScreen anti-phishing/anti-malware filter) operate automatically and require no changes to Web pages or add-ons. However, other security improvements will impact Web applications and browser add-ons. This article describes how to take advantage of these new Internet Explorer security features to help protect Web users and applications.

As we designed Internet Explorer 8 Beta 2, Microsoft security teams researched the common attacks in the wild and the trends that suggest where attackers will be focusing their attention next. For each class of attack, we developed a set of layered mitigations to provide defense-in-depth protection against exploits. Broadly speaking, there are two classes of threat that developers need to be concerned about: threats to Web applications, and threats to users' computers.

Web Application Threats

As more and more applications and user data migrate to the Web, attackers are ever more interested in attacking Web applications. While attacks against server-side code (for instance, buffer overflows, SQL injection, etc) remain popular, cross-site scripting (XSS) attacks have become the most common class of software vulnerability. XSS attacks exploit vulnerabilities in Web applications in order to steal cookies or other data, deface pages, steal credentials, or launch more exotic attacks.

The XSS Filter

Internet Explorer 8 Beta 2 helps to mitigate the threat of XSS attacks by blocking the most common form of XSS attack (called a reflection attack). In a reflection attack, data from a HTTP request (e.g. a query string parameter or POST body) is “reflected” back in the HTTP response without proper output-encoding. That reflected script runs in the context of the returned page, leading to a script injection exploit.

XSS attacks have become the most common class of software vulnerability.

The new XSS Filter operates as an Internet Explorer 8 Beta 2 component with visibility into all requests and responses flowing through the browser. When the filter's heuristics discover script being sent in a cross-site request, it identifies and neuters the script if it is subsequently replayed in the server's HTML response.

Figure 1 shows a case where the XSS Filter has identified a cross-site scripting attack in the URL. It has neutered this attack as the identified script was replayed back into the response page. In this way, the filter effectively blocks the attack without modifying the initial request to the server or completely blocking the entire response.

Figure 1: An Information Bar alerts users when the XSS Filter modifies a page.

In the unlikely event that you wish to disable the filter for your pages, you can do so by setting a HTTP response header:

X-XSS-Protection: 0

The XSS Filter helps block the most common XSS attacks, but it cannot possibly mitigate all XSS vulnerabilities. It's important that Web developers provide additional defense-in-depth and work to eliminate XSS vulnerabilities in their sites. Preventing XSS on the server-side is much easier that catching it at the browser; simply never trust user input! Most Web platform technologies offer one or more sanitization technologies-developers using ASP.NET should consider using the Microsoft Anti-Cross Site Scripting Library. To further mitigate the threat of XSS cookie theft, sensitive cookies (especially those used for authentication) should be protected with the HttpOnly attribute.

Safer Mashups

While the XSS Filter helps mitigate reflected scripting attacks when navigating between two servers, in the Web 2.0 world, Web applications are increasingly built using client-side mashup techniques.

Unfortunately, many mashups are built unsafely, relying SCRIPT SRC techniques that simply merge scripting from a third-party directly into the mashup page, providing the third-party full access to the DOM and non-HttpOnly cookies.

<html>
<head><title>MyMashup</title>
<script language="javascript" src="http://untrusted.example.com"></script>
</head>
<body>This page includes a script file from another domain. That script obtains full access to this document and its cookies.</body>
</html>

To help developers build more secure mashups, Internet Explorer 8 Beta 2 includes support for the HTML 5 cross-document messaging feature. The new postMessage call enables IFRAMEs to communicate more securely while maintaining DOM isolation. The frames communicating via postMessage do not get direct DOM access, but can only send string messages to each other. Each message clearly identifies its origin, and the varTargetUri parameter helps ensure that messages are not misdirected.

var o = document.getElementsByTagName('iframe')[0];

// PostMessage will only deliver the 'Hello' message to frame 'o' if it is currently at recipient.example.com
o.contentWindow.postMessage('Hello', 'http://recipient.example.com');

Internet Explorer 8 Beta 2 also introduces the XDomainRequest object to permit secure cross-domain retrieval of “public” data using HTTP. For more information, see “Better AJAX Development with Internet Explorer 8 Beta 2,” in this issue.

While HTML 5 Cross-Document Messaging and XDomainRequest both help to build secure mashups, a critical threat remains. When using either technique, the string data retrieved from the third-party frame or server could contain malicious script. If the calling page blindly injects the string into its own DOM, a script injection attack will occur. To help eliminate this threat, two new technologies can be used in concert with these cross-domain communication mechanisms to mitigate script-injection attacks.

Safer Mashups: HTML Sanitization

Internet Explorer 8 Beta 2 exposes a new method on the window object named toStaticHTML. When a string of HTML is passed to this function, any potentially executable script constructs are removed before the string is returned. Internally, this function is based on the same technologies as the server-side Microsoft Anti-Cross Site Scripting Library mentioned previously. So, for example, you can use toStaticHTML to help ensure that HTML received from an HTML 5 postMessage call cannot execute script, but can take advantage of basic formatting:

document.attachEvent('onmessage',function(e) {
    if (e.domain == 'weather.example.com') {
        spnWeather.innerHTML = window.toStaticHTML(e.data);
    }
});

Calling:

window.toStaticHTML("This is some <b>HTML</b>with embedded script following...<script>alert('bang!');</script>!");

will return:

This is some <b>HTML</b> with embedded script following... !

The sanitized string can be safely injected into the DOM without the possibility of script execution.

Safer Mashups: JSON Sanitization

JavaScript Object Notation (JSON) is a lightweight string-serialization of a JavaScript object that is often used to pass data between components of a mashup. Unfortunately, many mashups use JSON insecurely, relying on the JavaScript eval method to “revive” JSON strings back into JavaScript objects, potentially executing script functions in the process. Security-conscious developers instead use a JSON-parser to ensure that the JSON object does not contain executable script, but there's a performance penalty for this. Internet Explorer 8 Beta 2 implements the ECMAScript 3.1 proposal for native JSON-handling functions (which uses Douglas Crockford's json2.js API).

DEP/NX helps to foil attacks by preventing code from running in memory that is marked non-executable.

The JSON.stringify method accepts a script object and returns a JSON string, while the JSON.parse method accepts a string and safely revives it into a JavaScript object. The new native JSON methods are based on the same code used by the script engine itself, and thus have significantly improved performance over non-native implementations.

If the resulting object contains strings bound for injection into the DOM, the previously described toStaticHTML function can be used to prevent script injection.

Listing 1 uses both JSON and HTML sanitization to prevent script injection, even if the weather service returns a malicious response containing script:

HTTP/1.1 200 OK
Content-Type: application/json
Access-Control-Allow-Origin: allow *

{
    "Weather": {
        "City":"Seattle",
        "Zip":98052,
        "Forecast": {
            "Today":"Sunny",
            "Tonight": "<script defer>alert('bang!')</script>Dark",
            "Tomorrow":"Sunny"
        }
    }
}

Listing 1: Use JSON and HTML Sanitization to prevent script-injection

<html>
<head>
    <title>XDR+JSON Test Page</title>
    <script>
    if (window.XDomainRequest){
        var xdr = new XDomainRequest();
        
        xdr.onload = function() {
            var objWeather = JSON.parse(xdr.responseText);
            var oSpan = window.document.getElementById("spnWeather");
            oSpan.innerHTML = window.toStaticHTML("Tonight it will be <b>" + objWeather.Weather.Forecast.Tonight + "</b> in <u>" + objWeather.Weather.City + "</u>.");
        };
    
        xdr.open("POST", "http://evil.example.com/getweather.aspx";);
        xdr.send("98052");
    }
    </script>
</head>
<body>
    <span id="spnWeather"></span>
</body>
</html>

MIME-Handling Changes

Each type of file delivered from a Web server has an associated MIME type (also called a “content-type”) that describes the nature of the content (for instance, image, text, application, etc).

For legacy compatibility reasons, Internet Explorer has a MIME-sniffing feature that will attempt to determine the content-type for each downloaded resource. In some cases, Internet Explorer reports a MIME type different than the type specified by the Web server. For instance, if Internet Explorer finds HTML content in a file delivered with the HTTP response header Content-Type: text/plain, Internet Explorer determines that the content should be rendered as HTML. Due to the prevalence of legacy servers on the Web (for instance, those that serve all files as text/plain) MIME-sniffing remains an important compatibility feature.

Unfortunately, MIME-sniffing also can lead to security problems for servers hosting untrusted content. Consider, for instance, the case of a picture-sharing Web service which hosts pictures uploaded by anonymous users. An attacker could upload a specially crafted JPEG file that contained script content, and then send a link to the file to unsuspecting victims. When the victims visited the server to view the “picture”, the malicious file would be downloaded, the script would be detected, and it would run in the context of the picture-sharing site. This script could then steal the victim's cookies, generate a phony page, etc.

To combat this threat, we've made a number of changes to the Internet Explorer 8 Beta 2 MIME-type determination code.

MIME-Handling: Restricting Images

First, Internet Explorer 8 Beta 2 prevents “upsniff” of files served with image/* content types into HTML+script. Even if a file contains script, if the server declares that it is an image, IE will not run the embedded script. This change mitigates the picture-sharing attack vector-with no code changes on the part of the server. We were able to make this change by default with minimal compatibility impact only because servers rarely knowingly send HTML or script with an image/* content type.

MIME-Handling: Sniffing Opt-Out

Next, we've provided Web applications with the ability to opt-out of MIME-sniffing. Sending the new X-Content-Type-Options response header with a value of nosniff prevents Internet Explorer from MIME-sniffing a response away from the declared content-type. For example, consider the following HTTP-response:

HTTP/1.1 200 OK
Content-Length:108
Content-Type:text/plain
X-Content-Type-Options: nosniff

<html>
<body bgcolor="#AA0000">This page renders as HTML source code (text) in Internet Explorer 8 Beta 2. </body>
</html>

In Internet Explorer 7, the text is interpreted as HTML, as shown in Figure 2. In Internet Explorer 8 Beta 2, thanks to the nosniff option, the page is rendered as plaintext, as shown in Figure 3.

Figure 2: MIME-sniffing results in this page being rendered as HTML.

Figure 3: When the server opts-out of MIME-sniffing, the page is rendered as plain text.

The nosniff option puts servers in control of MIME-sniffing, enabling servers that host untrusted content to reliably control IE's interpretation of that content, helping to prevent script-injection attacks.

MIME-Handling: Force Save

Lastly, for Web applications that need to serve untrusted HTML files, we have introduced a mechanism to help prevent the untrusted content from compromising your site's security. When the new X-Download-Options header is present with the value noopen, Internet Explorer prevents the user from opening a file download directly; instead, they must first save the file locally. When the locally saved file is later opened, it no longer executes in the security context of your site, helping to prevent script injection.

HTTP/1.1 200 OK
X-Download-Options: noopen
Content-Disposition: attachment;
filename=untrustedfile.html
Content-Length: 238
Content-Type: text/html

<html>...

Taken together, the new cross-domain communication APIs, content-sanitization APIs, and MIME-sniffing improvements enable the construction of significantly more secure Web applications.

Threats to Users' Computers

While Web application attacks are becoming more common, attackers are always interested in compromising ordinary users' local computers. In order to allow the browser to effectively enforce security policy to protect Web applications, personal information, and local resources, attacks against the browser must be prevented.

Per-Site ActiveX is a defense mechanism to help prevent malicious repurposing of controls

Internet Explorer 7 made major investments in this space, including Protected Mode, ActiveX Opt-in, and Zone Lockdowns. In response to the hardening of the browser itself, attackers are increasingly focusing on compromising vulnerable browser add-ons. For Internet Explorer 8 Beta 2, we've made a number of investments to improve add-on security, reduce attack surface, and improve developer and user experience.

Data Execution Prevention (DEP/NX)

Internet Explorer 7 on Windows Vista introduced an off-by-default Internet Control Panel option to “Enable memory protection to help mitigate online attacks.” This option is also referred to as Data Execution Prevention (DEP) or No-Execute (NX).

We have enabled this option by default for Internet Explorer 8 Beta 2 on Windows Server 2008, Windows Vista SP1, and Windows XP SP3.

DEP/NX helps to foil attacks by preventing code from running in memory that is marked non-executable. DEP/NX, combined with other technologies like Address Space Layout Randomization (ASLR), make it harder for attackers to exploit certain types of memory-related vulnerabilities like buffer overruns. Best of all, the protection applies to both Internet Explorer and the add-ons it loads. No additional user interaction is required to provide this protection, and no new prompts are introduced.

For Internet Explorer 7, DEP/NX was disabled by default for compatibility reasons. Several popular add-ons were not compatible with DEP/NX and would crash when Internet Explorer loaded them with DEP/NX enabled. The most common problem was that these add-ons were built using an older version of the ATL library. Before version 7.1 SP1, ATL relied upon dynamically generated code in a way not compatible with DEP/NX.

While developers of many popular add-ons have since released updated extensions compatible with DEP/NX, some add-ons may not be updated before Internet Explorer 8 Beta 2 becomes available. Fortunately, new DEP/NX APIs have been added to Windows Server 2008 and recent Windows Service Packs to enable use of DEP/NX while retaining compatibility with older ATL versions. These new APIs allow Internet Explorer to opt-in to DEP/NX without causing add-ons built with older versions of ATL to crash.

Local Administrators can control DEP/NX by running Internet Explorer as an Administrator and unchecking the Tools > Internet Options > Advanced > “Enable memory protection to help mitigate online attacks” option.

You can see which processes are protected by DEP/NX on Windows Vista Task Manager's Process tab; on earlier versions of Windows, you can use Process Explorer. In either case, ensure that the “Data Execution Prevention box” is checked in the View > Select Columns menu.

If you build Internet Explorer add-ons, you can help ensure users enjoy a smooth upgrade to Internet Explorer 8 Beta 2 by taking the following steps:

Per-Site ActiveX

A key attack surface reduction we made for Internet Explorer 8 Beta 2 is “Per-Site ActiveX,” a defense mechanism to help prevent malicious repurposing of controls.

When a user navigates to a Web site containing an ActiveX control, Internet Explorer 8 Beta 2 performs a number of checks, including a determination of where a control is permitted to run.

If a control is installed, but is not permitted to run on a specific website, an Information Bar appears (Figure 4) asking the user whether or not the control should be permitted to run on the current website.

Figure 4: The Per-Site ActiveX information bar allows users to choose where an add-on may run.

End-users may adjust their per-site ActiveX settings using the Manage Add-ons dialog box. IT Professionals administering a system of computers running Internet Explorer 8 Beta 2 may choose to preset allowed controls and their associated domains. Such settings can be configured using Group Policy.

If your ActiveX control is designed for use only on your website and you do not wish to allow user-override, you should use the Microsoft SiteLock ATL Template to prevent your control from being used on other websites. Using the SiteLock template helps ensure that your control cannot be maliciously repurposed by other websites.

If an ActiveX control meets the requirements to place itself on the PreApproved list and has done so by listing the CLSID of the control within the following registry key, then the Per-Site ActiveX restriction is not applied to that control.

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\
Ext\PreApproved

Application Protocol Prompting

While ActiveX controls are a prime target for attackers, some enterprising attackers have started to look for exploitable attack surfaces in processes that can be automatically launched by the browser.

Application Protocol handlers enable third-party applications (such as streaming media players and Internet telephony applications) to directly launch from within the browser or other programs in Windows. Unfortunately, while this functionality is quite powerful, it presents a significant amount of attack surface, because some applications registered as protocol handlers may contain vulnerabilities that could be triggered from untrusted content from the Internet.

Applications handling URL protocols must be robust in the face of malicious data. Because handler applications receive data from untrusted sources, the URL and other parameter values passed to the application may contain malicious data attempting to exploit the handling application. For this reason, handling applications that could initiate unwanted actions based on external data must first confirm those actions with the user.

To help ensure that the user remains in control of their browsing experience, Internet Explorer 8 Beta 2 will now prompt before launching application protocols, as shown in Figure 5.

Figure 5: Internet Explorer now prompts before launching application protocol handlers.

To provide defense-in-depth, Application Protocol developers should ensure that they follow the Best Practices described on MSDN to ensure that handling applications are robust even when presented with malicious URLs.

Protected Mode Overview

Introduced in Internet Explorer 7 on Windows Vista, Protected Mode helps reduce the severity of threats to both Internet Explorer and extensions running in Internet Explorer by helping to prevent silent installation of malicious code even in the face of software vulnerabilities (Figure 6). For Internet Explorer 8 Beta 2, we've made a number of API improvements to Protected Mode to make it easier for add-on developers to control and interact with Protected Mode browser instances.

Figure 6: Internet Explorer 7 introduced the Protected Mode architecture to help prevent silent installation of malicious code.

Protected Mode Improvements: NewProcess Event

Unfortunately, when an application needs to programmatically start, interact with, and maintain a Protected-Mode Internet Explorer 7 process, it is unable to easily do so. When a program induces a CoCreateInstance of Internet Explorer, the Internet Explorer COM server is started with the program's integrity level. If the client application provides a URL to navigate, the Internet Explorer server will redirect the navigation into a Protected-Mode Internet Explorer process, and subsequently no information will be fed back to the controlling client application. The client's interface pointer becomes defunct and the client is no longer able to communicate to the actual Internet Explorer process performing the navigation (Figure 7).

Figure 7: Redirection of navigations into Protected Mode make it difficult to monitor Internet Explorer instances.

The Internet Explorer 8 Beta 2 architecture solves this problem with the newly added NewProcess event on the DWebBrowserEvents2 interface.

void NewProcess(long lCauseFlag, IDispatch *pWB2, VARIANT_BOOL *Cancel );

This event is fired before a redirection into a Protected Mode instance occurs. This permits the client application to track the new instance using the pWB2 pointer, or can cancel the navigation by setting the Cancel parameter to VARIANT_TRUE.

Protected Mode Improvements: Cookie-Sharing

Protected Mode restricts file writes (including cookies) to low integrity locations-this means that attempts to use the InternetGetCookie or InternetSetCookie APIs from a medium integrity application will fail to get or set cookies from Protected Mode Internet Explorer. In Internet Explorer 8 Beta 2, medium integrity applications can easily access low integrity cookies by using the new IEGetProtectedModeCookie and IESetProtectedModeCookie APIs. As always, applications that use interact with untrusted Internet data should be coded to assume that such data could be malicious. Before calling these APIs, be sure to check IEIsProtectedModeURL; calling these Protected Mode APIs against URLs that do not open in Protected Mode will return an error. Calling these APIs from an elevated (high integrity) process will also return an error.

Protected Mode Now Off in the Intranet Zone

For improved performance and lower application compatibility risk to organizations with ActiveX-based line-of-business sites, the Intranet Zone will run outside of Protected Mode in Internet Explorer 8 Beta 2.

In Internet Explorer 7, Protected Mode was enabled in the Intranet Zone only for user-experience reasons. When entering or leaving Protected Mode, Internet Explorer 7 was forced to create a new process and hence a new window-a serious user-experience annoyance. The Internet Explorer 8 Beta 2 loosely-coupled architecture (Figure 8) enables hosting of both Protected Mode and non-Protected Mode tabs within the same browser window, eliminating the need to launch a new window. Of course, Internet Explorer 8 Beta 2 users and domain administrators have the option to re-enable Protected Mode for Intranet Zone if desired.

Figure 8: Internet Explorer 8 Beta 2's new Process model.

File Upload Control

Historically, the HTML File Upload Control () has been the source of a number of information disclosure vulnerabilities. To resolve these issues, two changes were made to the behavior of the control.

To block attacks that rely on “stealing” keystrokes to surreptitiously trick the user into typing a local file path into the control (which is later surreptitiously submitted), the File Path edit box is now read-only (Figure 9). The user must explicitly select a file for upload using the File Browse dialog.

Figure 9: The File Upload Control edit box is now read-only.

Additionally, the “Include local directory path when uploading files” URLAction has been set to “Disable” for the Internet Zone. This change prevents leakage of potentially sensitive local file-system information to the Internet. For instance, rather than submitting the full path:

C:\users\ericlaw\documents\secret\image.png

Internet Explorer 8 Beta 2 will now submit only the filename

image.png

Conclusion

Security is a core characteristic of trustworthy browsing, and Internet Explorer 8 Beta 2 includes major improvements to address the evolving Web security landscape. The Internet Explorer team is working to help protect users and provide new ways to enhance Web application security.

Internet Explorer 8 Beta 2 will now prompt before launching application protocols.

Thanks for your help in securing the Web!