Use HTTP-only cookies to mitigate cross-site scripting attacks

Author: Kang Kai

First, we briefly explained HTTP-only cookies and cross-site scripting attacks, and then explained in detail how to use HTTP-only cookies to protect sensitive data, finally, this article introduces how to determine the browser version when implementing HTTP-only cookies.

1. Introduction to XSS and HTTP-only cookies

Cross-site Scripting is one of the common problems that plague Web server security. Cross-site Scripting is a server-side security vulnerability. It is common when user input is submitted as HTML, the server does not perform proper filtering. Cross-site scripting attacks may cause leakage of sensitive information of Web site users. To reduce the risk of cross-site scripting attacks, Microsoft Internet Explorer 6 SP1 introduces a new feature.

This feature provides a new attribute for cookies to prevent client scripts from accessing cookies.

A cookie with this attribute is called an HTTP-only cookie. The probability of exposing any information contained in HTTP-only cookies to hackers or malicious websites is greatly reduced. The following is an example of setting an HTTP-only cookie header:

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

The preceding section describes HTTP-only cookies; next, we will introduce the potential risks caused by cross-site scripting attacks, cookie Access through scripts, and how to reduce the risk of cross-site scripting attacks through HTTP-only.

Cross-site Scripting is a common security vulnerability on the server. It allows hackers to fool users and cause leakage of sensitive information on a Web site. The following describes how to perform cross-site scripting.

Ii. Cross-site scripting attack example

To explain how cross-site scripting attacks are exploited by hackers, we assume the following example:

A securities company runs A Web site that allows you to track the latest prices of A stock. To improve user experience, after logging on to the website of A securities company, you will be redirected to www.azhengquan.com/default.asp? Name = <script> evilScript () </script> Zhang San, and a server-side script generates a welcome page with the content "Welcome Back, Zhang San !".

Your stock data is stored in a database, and the Web site places a cookie on your computer, which contains data that is very important to this database. The browser automatically sends the cookie whenever you visit the website of A securities company.

A hacker finds that the website of A securities company has A cross-site scripting attack defect, so he decided to use this to collect sensitive information such as the name of your stock. The hacker will send you an email claiming that you have won the prize and you need to click a link such as "Click here" to get the prize. Note: this link will be hyperlink to asp? Name "> www.azhengquan.com/default.asp? Name = <script> evilScript () </script> when you click this link, you will see "welcome back !" -- Wait. Where is your name? In fact, after you click the link in the email, you are actually notifying the website of A securities company. Your name is <script> evilScript () </script>. The Web server returns the HTML generated by the "name" to you, but your browser will interpret the "name" as the script code, after the script is executed, the previous scene is displayed. Generally, supporting client scripts is one of the typical features of browsers. If the script command browser sends a cookie to the hacker's computer, even if the cookie contains information about your stock, your browser will execute it honestly. Finally, the instructions from the website of A securities company obtain the cookie containing sensitive information.

The following is a cross-site scripting attack, which details the five steps of the attack. First, the user clicks an embedded link (step 1) in the hacker's email ). Because of the vulnerability in Cross-Site Scripting, this will cause the user's browser to send a request to the Web site (step 1). Based on this request, the server generates a response containing malicious scripts, and send it back to the user's browser (step 1 ). When the user's machine executes the returned malicious code (step 1), it will send the user's sensitive data to the hacker's computer (step 2 ).

Figure 1

We can see that in this process, the user only needs to click a link, and then there will be instructions sent to the Web server, and then the Web server generates a Web page embedded with malicious scripts; the browser runs the script from a trusted source, causing information leakage to the hacker's computer. There are many different types of cross-site scripting attacks. Here is only one of them.

3. Use HTTP-only cookies to protect data

To mitigate the risk of information leakage caused by cross-site scripting attacks, Internet Explorer 6 SP1 introduces a new attribute for cookies. This attribute specifies that the cookie cannot be accessed through scripts. After the HTTP-only Cookie is used, the Web site can eliminate the possibility that the sensitive information in the cookie is sent to the hacker's computer or the Web site using the script.

Cookies are usually sent to the client as HTTP Response hair. The following example shows the corresponding syntax (note that the HttpOnly attribute is not case sensitive ):

Set-Cookie: = [; =]
[; Expires =] [; domain =]
[; Path =] [; secure] [; HttpOnly]

Even if the response header contains the HttpOnly attribute, the cookie is automatically sent when the user browses the site in the valid domain. However, the cookie cannot be accessed using a script in Internet Explorer 6 SP1, even if the website that initially created the cookie is no exception. This means that Internet Explorer will not send the cookie to any third party even if there is a cross-site scripting vulnerability and the user is cheated to click the link to exploit the vulnerability. This ensures information security.

Note: to reduce the damage caused by cross-site scripting attacks, HTTP-only cookies and other technologies are usually used in combination. If it is used independently, it cannot fully defend against cross-site scripting attacks.

4. Browsers supporting HTTP-only cookies

If a Web site creates an HTTP-only Cookie for a browser that does not support HTTP-only cookies, the cookie is either ignored or downgraded to a common cookie that can be accessed through a script. This will lead to information leakage easily.

For web pages in the company's Intranet, the administrator can ask all users to use browsers that support HTTP-only cookies. This ensures that information is not leaked due to cross-site scripting attacks.

For public Web sites, because they need to support a variety of browsers, you can consider using the client script to determine the version of the browser used by different visitors. The Web site can support ~ To reduce the Cookie threat caused by cross-site scripting attacks. Visitors who use browsers that do not support HTTP-only cookies can restrict the information or functions provided for them and require upgrading their software.

When determining the version of Internet Explorer, it is important to remember that the user proxy string of Internet Explorer 6 SP1 is the same as that of Internet Explorer 6. The client script must also use the appMinorVersion attribute of the navigator object to check whether Internet Explorer 6 SP1 is installed on the client.

V. Summary

In the field of Web security, cross-site scripting is the most common form of attacks, which has long been an old and difficult problem, this article will introduce a technology to ease this pressure, namely, HTTP-only cookie. First, we briefly explained HTTP-only cookies and cross-site scripting attacks, and then explained in detail how to use HTTP-only cookies to protect sensitive data, finally, this article introduces how to determine the browser version when implementing HTTP-only cookies.