Mitigate XSS pain with http-only cookies

In web security, one of the most common forms of attack in a cross-site scripting attack is a long-standing problem, and this article introduces readers to a technique to alleviate this stress, the http-only cookie.

We first gave a simple explanation of http-only cookies and cross-site scripting attacks, then explained in detail how to use http-only cookies to protect sensitive data, and finally introduced the specific issue of determining the browser version when implementing Http-only cookies.

I. Introduction to XSS and Http-only cookies

Cross-site scripting is one of the common problems that plague Web server security. Cross-site scripting attacks are a server-side security vulnerability that is often caused by the server side not being properly filtered when the user's input is submitted as HTML. Cross-site scripting attacks can cause sensitive information to leak Web site users. To reduce the risk of cross-site scripting attacks, Microsoft's Internet Explorer 6 SP1 introduces a new feature.

This feature provides a new property for cookies that prevent client script from accessing cookies.

A cookie like this that has this attribute is called a http-only cookie. Any information contained in the HTTP-ONLY cookie will be significantly less likely to be exposed to hackers or malicious websites. The following is an example of setting a header for the http-only cookie:

set-cookie:user=123; Expires=wednesday, 09-nov-99 23:12:40 GMT; HttpOnly

We introduced the Http-only cookie above, and we begin to introduce readers to the potential dangers of cross-site scripting attacks, cookies that allow access to scripts, and how to mitigate the risk of cross-site scripting attacks through Http-only.

Cross-site scripting attacks are a common server-side security vulnerability that allows hackers to trick users into leaking sensitive information on a Web site. The following is a simple example that explains the steps involved in a cross-site scripting attack.

Second, cross-site Scripting attack example

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

A securities company runs a Web site that allows you to track the latest price of a stock. To improve the user experience, after logging in to a securities company's Web site, you will be redirected to Www.azhengquan.com/default.asp?name = < script > evilscript () </script & gt; Zhang San, and there is a server-side script to generate 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 that contains data that is important to the database. Whenever you visit a securities company site, the browser automatically sends the cookie.

A hacker discovers that a security company's Web site has a cross-site scripting flaw, so he decides to use this to collect sensitive information such as the name of the stock you hold. The hacker will send you an email stating that you have won the lottery and that you need to click on a link such as "Click here" to collect the prize. Note that the link will hyperlink to www.azhengquan.com/default.asp?name=< script >evilscript () </SCRIPT > When you click on this link, you will be greeted with " You are welcome to come back! "--wait, where's your name? In fact, after clicking the link in the email, you are actually notifying a securities company's Web site that your name is < script > Evilscript () </script >. The Web server returns the HTML generated with this "name" to you, but your browser interprets the "name" as a script code, and after the script executes, there is a scene we saw earlier. In general, supporting client-side scripting is one of the typical features of a browser. If the script commands the browser to send a cookie back to the hacker's computer, even if the cookie contains information about your stock, your browser will do so honestly. Finally, the instructions from a security company's Web site Obtain the cookie that contains the sensitive information.

The following is a cross-site scripting attack, which shows the five steps of the attack in detail. First, the user clicked on an embedded link in the email sent by the hacker (1th step). Because of the vulnerability of cross-site scripting, this causes the user's browser to send a request to the Web site (2nd); The server side generates a response that contains a malicious script based on the request and sends it back to the user's browser (step 3rd). When the user's machine executes the returned malicious code (step 4th), the user's sensitive data is sent to the hacker's computer (step 5th).

We can see that this process only requires the user to click on a link, then there will be instructions sent to the Web server, and then the Web server generates a malicious script embedded Web page, the browser run this from a trusted source script, but the information leaked to the hacker's computer. There are many different forms of cross-site scripting attacks, and this is just one of them.

Third, protect data with http-only cookie

To mitigate the risk of information breaches from cross-site scripting attacks, Internet Explorer 6 SP1 introduces a new attribute to cookies. This attribute specifies that cookies are not allowed to be accessed through a script. With http-only cookies, Web sites can exclude the possibility that sensitive information in cookies is sent to hackers ' computers or Web sites using scripts.

A cookie is usually sent to the client as an HTTP answer, and the following example shows the syntax (note that the HttpOnly property is not case sensitive):

Set-cookie: =[; =]
[; expires=] [; domain=]
[; Path=] [; secure] [; HttpOnly]

Even if the answer header contains the HttpOnly attribute, the cookie is automatically sent when the user browses to a site in the active domain. However, it is not possible to use a script in Internet Explorer 6 SP1 to access the cookie, even if the Web site where the cookie was originally created is no exception. This means that Internet Explorer does not send the cookie to any third party, even if there is a cross-site scripting attack flaw and the user is tricked into clicking a link that exploits the vulnerability. In this way, the security of the information is ensured.
Note that in order to mitigate the damage caused by cross-site scripting attacks, it is often necessary to combine http-only cookies with other technologies. If used alone, it does not fully protect against cross-site scripting attacks.

Iv. browsers that support http-only cookies

If a Web site establishes a http-only cookie for a browser that does not support http-only cookies, then the cookie is either ignored or degraded to a normal cookie that can be accessed through a script. This can also lead to information being easily leaked.

For Web pages in the corporate intranet, administrators can require that all users are browsers that support http-only cookies, which ensures that information is not compromised by cross-site scripting attacks.

For public Web sites, you might consider using client-side scripting to determine the version of the browser used by different visitors because of the need to support a wide variety of browsers. Web sites can mitigate the threat to cookies from cross-site scripting attacks by sending sensitive information to a browser that supports ~. Visitors who use browsers that do not support http-only cookies can limit the information or functionality provided to them and request that their software be upgraded.

When determining the version of Internet Explorer, it is important to remember that the user agent string for Internet Explorer 6 SP1 is the same as the user agent string for Internet Explorer 6. Client script must also use the appMinorVersion property of the Navigator object to detect the major version number in order to determine if the client has Internet Explorer 6 SP1 installed.

V. Summary

In the field of web security, one of the most common forms of attack in a cross-site scripting attack is a long-standing problem, and this article introduces readers to a technique to alleviate this stress, the http-only cookie. We first gave a simple explanation of http-only cookies and cross-site scripting attacks, then explained in detail how to use http-only cookies to protect sensitive data, and finally introduced the specific issue of determining the browser version when implementing Http-only cookies.

1. What is HttpOnly?

If you set the HttpOnly attribute in the cookie, the cookie information cannot be read by the JS script, which can effectively prevent XSS attacks.

Please search Google for a specific introduction

Does the 2.javaEE API support?

At present, Sun has not released the relevant API, but PHP, C # are implemented. Java EE brothers are more depressed, do not worry about the following flexible implementation

Sample setup for 3.HttpOnly

Java EE

Response.setheader ("Set-cookie", "cookiename=value; path=/;D Omain=domainvalue; Max-age=seconds; HttpOnly ");

The meaning of the specific parameter is not elaborated again, after the set up through the JS script is not read the cookie, but use the following way can read

Cookie cookies[]=request.getcookies ();

C#

HttpCookie MyCookie = new HttpCookie ("MyCookie"); Mycookie.httponly = true; Response.appendcookie (MyCookie);

PHP4

Header ("Set-cookie:hidden=value; HttpOnly ");

PHP5

Setcookie ("abc", "Test", NULL, NULL, NULL, NULL, TRUE);

Mitigate XSS pain with http-only cookies