A discussion on cookie security

In Web apps, cookies can easily be part of a security issue. From past experience, the use of cookies in the development process, many development teams have not formed a consensus or a certain specification, which also makes many applications in the cookie becomes a potential vulnerable point of attack. When it comes to security architecture review for WEB applications, I usually ask designers the following questions:

1. Do you use JavaScript to manipulate client-side cookies in your app? If so, do you have to use JavaScript to complete this scenario? If not, does your Cookie allow JavaScript to be accessed?
2. How does your Web site (which may contain multiple WEB apps) develop policies for the domain (domains) and path settings for cookies? Why is this divided?
3. In an application with SSL, can your Cookie be used in HTTP requests and HTTPS requests?

In a real-world scenario, the one thing that cookies are used to do most is to maintain the status of the server that is being authenticated. This retention may be session-based, or persistent. In either case, the service-side ticket (Ticket) that is contained in the authentication Cookie will be difficult to distinguish from the real user, or from a malicious attacker, if the user's request with the ticket is compromised. In real-world cases, the most common way to disclose cookies is through a cross-site scripting (XSS) vulnerability. An attacker could use a small piece of JavaScript code to steal an important Cookie mark that represents the user's identity. Because cross-site scripting vulnerabilities are so pervasive (do not assume that simple HTML Encode can be avoided by cross-site, cross-site is a very deep learning, so that in the industry derived a dedicated noun: cross-site division), almost every site can not be avoided, so this approach is the actual attack and defense is commonly used as a means.

The first secret to avoiding this problem is to do whatever it is possible to add a httponly tag to your Cookie. The specific use of httponly is not within the scope of this article, otherwise the author slightly cheated InfoQ of the suspicion of remuneration. A fact that is not familiar to everyone is that HttpOnly was first invented and supported by Microsoft in the 2000 IE6 SP1. As of now, HttpOnly is still only a vendor standard, but over the past more than 10 years, it has been widely supported by many browsers.

The following table is a summary of OWASP's support for HttpOnly in mainstream browsers. As can be seen from the table, the current mainstream browser, in addition to Android, almost no exception to this attribute is supported.

Of course, for Chinese developers, the issues to be considered are even more complicated: in this magical place, there are a large number of users using a browser that is not in the following list, they are using one or several of the following browsers as the kernel "hardcover" browser. The support of these browser vendors for security specifications such as homologous policy, HttpOnly Cookie, certificate management, etc. is pending further investigation.

Browser	Version	Prevents Reads	Prevents writes
Microsoft Internet Explorer	10	Yes	Yes
Microsoft Internet Explorer	9	Yes	Yes
Microsoft Internet Explorer	8	Yes	Yes
Microsoft Internet Explorer	7	Yes	Yes
Microsoft Internet Explorer	6 (SP1)	Yes	No
Microsoft Internet Explorer	6 (fully patched)	Yes	Unknown
Mozilla Firefox	3.0.0.6+	Yes	Yes
Netscape Navigator	9.0b3	Yes	Yes
Opera	9.23	No	No
Opera	9.5	Yes	No
Opera	11	Yes	Unknown
Safari	3	No	No
Safari	5	Yes	Yes
IPhone (Safari)	IOS 4	Yes	Yes
Google ' s Chrome	Beta (initial public release)	Yes	No
Google ' s Chrome	12	Yes	Yes
Android	Android 2.3	Unknown	Unknown

In my opinion, every Cookie in a Web app should be tagged with a httponly. I don't see the downside of this decision, and if you have to say so, then your app will no longer be able to read and write cookies through JavaScript. But is it really necessary? In my opinion, JavaScript is an unusual way to manipulate cookies, and you can use JavaScript to manipulate cookies to do the same thing, which can be done with the server-side response Http header setting cookie. Conversely, the huge benefits of setting up all cookies for httponly are obvious: although you need to continue to fix XSS vulnerabilities, these vulnerabilities will at least temporarily not cause your users to suffer large-scale account losses.

A second topic about cookies is domain settings.

The browser has a series of comparisons and screening when choosing which local cookies to send to the server of this request. The most important part of these screening is the coincidence of Domain and Path. Domain-shaped cookies, such as. abc.com, are sent to all abc.com on port 80 for subdomain requests. But otherwise, this is the Cookie's domain match principle.

In a large Web site, there are often multiple applications that live under different subdomains or paths. These apps can often have the ability to manipulate each other's app cookies because they share the same domain name. In this case, the Domain and Path to design the Cookie are particularly important. In the actual design work, the most important security principle is: Minimize authorization. This means that you need to minimize the extent to which your Cookie can be accessed. There are a lot of solutions for passing data and sharing information between apps, and sharing data through cookies, user input, is one of the least secure solutions.

Another attribute that is not often used in cookies is Secure. When this property is enabled, the browser simply sends the Cookie content to the server in the HTTPS request. If your application has a very sensitive business, such as login or payment, you need to use HTTPS to ensure the security of content transmission, and after the successful authorization of the user, the client identity Cookie is not set to Secure, it is likely to be a non-HTTPS page to get, Thus leading to an important identity leak. So, in your Web site, if SSL is used, you need to double-check the Cookie value returned in the SSL request and whether the Secure attribute is specified.

In addition, it is worth noting that some WEB applications, in addition to the cookies generated in their own program code, often generate some cookies from other sources. For example, a session cookie generated automatically by a Web Server or app container, a cookie generated by a third-party library or framework, and so on. These need to be targeted to strengthen the treatment.

It is difficult to leave cookies at almost every site, but the use of cookies is easy to despise because of their seemingly simple. A re-examination of the Cookie code in the app can make a huge security benefit for almost a small cost.

　　Reference articles

• Http://en.wikipedia.org/wiki/HTTP_cookie
• Https://www.owasp.org/index.php/HttpOnly

Copyright notice: I feel like I'm doing a good job. I hope you can move your mouse and keyboard for me to order a praise or give me a comment, under the Grateful!_____________________________________________________ __ Welcome reprint, in the hope that you reprint at the same time, add the original address, thank you with

A discussion on cookie security