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. |