One of the more common security problems plaguing Web servers is cross-site scripting. Cross-site scripting is a server-side vulnerability that is often created when rendering user input as HTML. Cross-site scripting attacks can expose sensitive information about the users of the Web site. In order to help mitigate the risk of cross-site scripting, a new feature has been introduced in Microsoft Internet Explorer 6. This feature is a new attribute for cookies which prevents them from being accessed through client-side script. A cookie with this attribute is called an HTTP-only cookie. Any information contained in an HTTP-only cookie is less likely to be disclosed to a hacker or a malicious Web site. The following example is a header that sets an HTTP-only cookie.

Set-Cookie: USER=123; expires=Wednesday, 09-Nov-99 23:12:40 GMT; HttpOnly

This topic briefly explains cross-site scripting, the potential risk of a cookie that can be accessed through script, and how this risk has been mitigated by HTTP-only cookies in Internet Explorer 6 Service Pack 1 (SP1).

• Cross-site Scripting
• • An Example of Cross-site Scripting
• Protecting Data with HTTP-only Cookies
• Browser Support for HTTP-only Cookies
• Related Topics

Cross-site Scripting

Cross-site scripting is a common server-side vulnerability which allows a hacker to trick a user into disclosing sensitive information that is normally reserved for a specific Web site. The various steps of a cross-site scripting attack can best be explained with a simple example.

An Example of Cross-site Scripting

To understand how cross-site scripting is typically exploited, consider the following hypothetical example.

The A. Datum Corporation runs a Web site that allows you to track the latest price of your stock portfolio. To add a friendly touch, after logging in to the A. Datum Web site, you are redirected to www.adatum.com/default.asp?name=Brian and a server-side script generates a welcome page that says "Welcome Back Brian!". The stocks in your portfolio are stored in a database, and the Web site places a cookie on your computer containing a key to that database. The cookie is retrieved anytime you visit the A. Datum Web site.

A hacker realizes that the A. Datum Web site suffers from a cross-site scripting bug and decides to exploit this to gather some information about you that you‘d rather not disclose; the names of the stocks in your portfolio. The hacker sends you an e-mail that claims you‘ve just won a vacation getaway and all you have to do is "click here" to claim your prize. The URL for the hypertext link is www.adatum.com/default.asp?name=<script>evilScript()</script>. When you click this link, the Web site tries to be friendly by greeting you, but instead displays, "Welcome Back !". What happened to your name? By clicking the link in the e-mail, you‘ve told the A. Datum Web site that your name is <script>evilScript()</script>. The Web server generated HTML with this "name" embedded and sent it to your browser. Your browser correctly interprets this as script, and because client-side script is typical browser functionality, runs the script without prompting you. If this script instructs the browser to send a cookie containing your stock portfolio to the hacker‘s computer, it quickly complies. After all, the instruction came from the A. Datum Web site which owns that cookie.

The following image demonstrates this concept visually by showing the process in five steps. First, the user clicks a link embedded in e-mail from the hacker (step 1). This generates a request to a Web site (step 2) which, because of a cross-site scripting bug, complies with the request and sends malicious script back to the user‘s browser (step 3). The script host executes the malicious code (step 4) and sends the sensitive data to the hacker‘s computer (step 5).

There are many variations on this example of cross-site scripting. For more examples and further details see Cross-site Scripting.

Protecting Data with HTTP-only Cookies

To mitigate the risk of information disclosure with a cross-site scripting attack, a new attribute is introduced to cookies for Internet Explorer 6 SP1. This attribute specifies that a cookie is not accessible through script. By using HTTP-only cookies, a Web site eliminates the possibility that sensitive information contained in the cookie can be sent to a hacker‘s computer or Web site with script.

A cookie is set on the client with an HTTP response header. The following example shows the syntax used in this header.

Set-Cookie: <name>=<value>[; <name>=<value>][; expires=<date>][; domain=<domain_name>][; path=<some_path>][; secure][; HttpOnly]

If the HttpOnly attribute is included in the response header, the cookie is still sent when the user browses to a Web site in the valid domain. The cookie cannot be accessed through script in Internet Explorer 6 SP1, even by the Web site that set the cookie in the first place. This means that even if a cross-site scripting bug exists, and the user is tricked into clicking a link that exploits this bug, Windows Internet Explorer does not send the cookie to a third party. The information is safe.

Browser Support for HTTP-only Cookies

If a Web site sets an HTTP-only cookie on a browser that does not support HTTP-only cookies, the cookie is either ignored or downgraded to a traditional, scriptable cookie. This leaves information vulnerable to attack for users of some browsers.

For a company intranet Web page, administrators could require the use of a browser that recognizes HTTP-only cookies for all users. This ensures that information is not disclosed with a cross-site scripting bug.

For a public Web site where it is important to support multiple browsers, consider using client-side script to determine the browser version for each visitor. The Web site can restrict sensitive information to visitors using browsers that mitigate cross-site scripting attacks for cookies. Visitors with browsers that do not support HTTP-only cookies can be given limited information or functionality along with a request to upgrade their software.

When determining the browser version of Internet Explorer, it is important to keep in mind that the user agent string for Internet Explorer 6 SP1 is identical to the user agent string for Internet Explorer 6. Client-side script must also check the minor version number with the appMinorVersion property of the navigator object to determine whether Internet Explorer 6 SP1 is installed.

Related Topics

• HTTP Cookies
• Cross-site Scripting
• Microsoft Security
• When Output Turns Bad: Cross-Site Scripting Explained

from:http://msdn.microsoft.com/en-us/library/ms533046.aspx