Hi! I’m Eric Lawrence, Security Program Manager for Internet Explorer. Last Tuesday, Dean wrote about our principles for delivering a trustworthy browser; today, I’m excited to share with you details on the significant investments we’ve made in Security for Internet Explorer 8. As you might guess from the length of this post, we’ve done a lot of security work for this release. As an end-user, simply upgrade to IE8 to benefit from these security improvements. As a domain administrator, you can use Group Policy and the IEAK to set secure defaults for your network. As web-developer, you can build upon some of these new features to help protect your users and web applications.
As we were planning Internet Explorer 8, our security teams looked closely at the common attacks in the wild and the trends that suggest where attackers will be focusing their attention next. While we were building new Security features, we also worked hard to ensure that powerful new features (like Activities and Web Slices) minimize attack surface and don’t provide attackers with new targets. Out of our planning work, we classified threats into three major categories: Web Application Vulnerabilities, Browser & Add-on Vulnerabilities, and Social Engineering Threats. For each class of threat, we developed a set of layered mitigations to provide defense-in-depth protection against exploits.
Web Application Defense
Cross-Site-Scripting Defenses
Over the past few years, cross-site scripting (XSS) attacks have surpassed buffer overflows to 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.
IE8 helps to mitigate the threat of XSS attacks by blocking the most common form of XSS attack (called “reflection” attacks). The IE8 XSS Filter is a heuristic-based mitigation that sanitizes injected scripts, preventing execution. Learn more about this defense in David’s blog post: IE8 Security Part IV - The XSS Filter.
XSS Filter provides good protection against exploits, but because this feature is only available in IE8, 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 clientside mashup techniques. 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.
To help developers build more secure mashups, for Internet Explorer 8, we’ve introduced support for the HTML5 cross-document messaging feature that enables IFRAMEs to communicate more securely while maintaining DOM isolation. We’ve also introduced the XDomainRequest object to permit secure network retrieval of “public” data across domains.
While Cross-Document-Messaging and XDomainRequest both help to secure mashups, a critical threat remains. Using either object, the string data retrieved from the third-party frame or server could contain script; if the caller blindly injects the string into its own DOM, a script injection attack will occur. For that reason, we’re happy to announce two new technologies that can be used in concert with these cross-domain communication mechanisms to mitigate script-injection attacks.
Safer Mashups: HTML Sanitization
IE8 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 a 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... !
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 implements the ECMAScript 3.1 proposal for native JSON-handling functions (which uses Douglas Crockford’s json2.js API). 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.
The following example uses both JSON and HTML sanitization to prevent script injection:
<html>
<head><title>XDR+JSON Test Page</title>
<script>
if (window.XDomainRequest){
var xdr1 = new XDomainRequest();
xdr1.onload = function(){
var objWeather = JSON.parse(xdr1.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>.");
};
xdr1.open("POST", "http://evil.weather.example.com/getweather.aspx");
xdr1.send("98052");
}
</script></head>
<body><span id="spnWeather"></span></body>
</html>
…even if the weather service returns a malicious response:
HTTP/1.1 200 OK
Content-Type: application/json
XDomainRequestAllowed: 1
{"Weather": {
"City": "Seattle",
"Zip": 98052,
"Forecast": {
"Today": "Sunny",
"Tonight": "<script defer>alert('bang!')</script>Dark",
"Tomorrow": "Sunny"
}
}}
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 (e.g. image, text, application, etc). For 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, IE determines that the content should be rendered as HTML. Because of the number of legacy servers on the web (e.g. those that serve all files as text/plain) MIME-sniffing is 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, 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 problem, we’ve made a number of changes to Internet Explorer 8’s MIME-type determination code.
MIME-Handling: Restrict Upsniff
First, IE8 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 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 authoritative=true attribute on the Content-Type HTTP response header 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
Date: Thu, 26 Jun 2008 22:06:28 GMT
Content-Type: text/plain; authoritative=true;
<html>
<body bgcolor="#AA0000">
This page renders as HTML source code (text) in IE8.
</body>
</html>
In IE7, the text is interpreted as HTML:
In IE8, the page is rendered in plaintext:
Sites hosting untrusted content can use the authoritative attribute to ensure that text/plain files are not sniffed to anything else.
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, the user is prevented 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
Content-Length: 238
Content-Type: text/html
X-Download-Options: noopen
Content-Disposition: attachment; filename=untrustedfile.html
Taken together, these new Web Application Defenses enable the construction of much more secure web applications.
Local Browser Defenses
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. 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, we’ve made a number of investments to improve add-on security, reduce attack surface, and improve developer and user experience.
Add-on Security
We kicked off this security blog series with discussion of DEP/NX Memory Protection, enabled by default for IE8 when running 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. You can read more about this defense in the original blog post: IE8 Security Part I: DEP/NX Memory Protection.
In a follow-up post, Matt Crowley described the ActiveX improvements in IE8 and summarized the existing ActiveX-related security features carried over from earlier browser versions. The key improvement we made for IE8 is “Per-Site ActiveX,” a defense mechanism to help prevent malicious repurposing of controls. IE8 also supports non-Administrator installation of ActiveX controls, enabling domain administrators to configure most users without administrative permissions. You can get the full details about these improvements by reading: IE8 Security Part II: ActiveX Improvements. If you develop ActiveX controls, you can help protect users by following the Best Practices for ActiveX controls .
Protected Mode
Introduced in IE7 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. For Internet Explorer 8, 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. You can read about these improvements in the Improved Protected Mode API Whitepaper.
For improved performance and application compatibility, by default IE8 disables Protected Mode in the Intranet Zone. Protected Mode was originally enabled in the Intranet Zone 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.
Internet Explorer 8’s Loosely Coupled architecture enables us to host both Protected Mode and non-Protected Mode tabs within the same browser window, eliminating this user-experience annoyance. Of course, IE8 users and domain administrators have the option to enable Protected Mode for Intranet Zone if desired.
Application Protocol Prompt
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.
To help ensure that the user remains in control of their browsing experience, Internet Explorer 8 will now prompt before launching application protocols.
To provide defense-in-depth, Application Protocol developers should ensure that they follow the Best Practices described on MSDN.
File Upload Control
Historically, the HTML File Upload Control (<input type=file>) has been the source of a significant 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, the File Path edit box is now read-only. The user must explicitly select a file for upload using the File Browse dialog.
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 will now submit only the filename image.png.
Social Engineering Defenses
As browser defenses have been improved over the last few years, web criminals are increasingly relying on social engineering attacks to victimize users. Rather than attacking the ever-stronger castle walls, attackers increasingly visit the front gate and simply request that the user trust them.
For Internet Explorer 8, we’ve invested in features that help the user make safe trust decisions based on clearly-presented information gathered from the site and trustworthy authorities.
Address Bar Improvements
Domain Highlighting is a new feature introduced in IE8 Beta 1 to help users more easily interpret web addresses (URLs). Because the domain name is the most security-relevant identifier in a URL, it is shown in black text, while site-controlled URL text like the query string and path are shown in grey text.
When coupled with other technologies like Extended Validation SSL certificates, Internet Explorer 8’s improved address bar helps users more easily ensure that they provide personal information only to sites they trust.
SmartScreen® Filter
Internet Explorer 7 introduced the Phishing Filter, a dynamic security feature designed to warn users when they attempt to visit known-phishing sites. For Internet Explorer 8, we’ve built upon the success of the Phishing Filter feature (which blocks millions of phishing attacks per week) and developed the SmartScreen® Filter. The SmartScreen Filter goes beyond anti-phishing to help block sites that are known to distribute malware, malicious software which attempts to attack your computer or steal your personal information. SmartScreen works in concert with other technologies like Windows Defender and Windows Live OneCare to provide comprehensive protection against malicious software.
You can read more about the new SmartScreen Filter in my earlier post: IE8 Security Part III - The SmartScreen Filter.
Summary
Security is a core characteristic of trustworthy browsing, and Internet Explorer 8 includes major improvements to address the evolving web security landscape. While the bad guys are unlikely to ever just “throw in the towel,” the IE team is working tirelessly to help protect users and provide new ways to enhance web application security.
Please stay tuned to the IEBlog for more information on the work we’re doing in Privacy, Reliability, and Business Practices to build a trustworthy browser.
Onward to Beta-2 in August!
Eric Lawrence
Program Manager
Internet Explorer Security
