[Web_cookie] Cookie Depth Analysis

Cookie Introduction

As we all know, the Web protocol (that is, HTTP) is a stateless protocol (HTTP1.0). A Web application consists of a number of web pages, each of which has a unique URL to define. The user enters the URL of the page in the address bar of the browser, and the browser sends the request to the Web server. For example, the browser sends two requests to the Web server and requests two pages. The requests for the two pages were using two separate HTTP connections respectively. The so-called stateless protocol is where the browser and Web server close the connection channel after the first request completes and reestablish the connection at the second request. The Web server does not distinguish which client the request is from, and all requests are treated equally, and are separate connections. This way is greatly different from the traditional (Client/server) C/s structure, in such applications, the client and the server side will establish a long-time dedicated connection channel. It is because of the stateless nature that every connection resource can be quickly reused by other clients, and a Web server can serve tens of thousands of clients at the same time.
But our usual application is stateful. Without mentioning SSO between different applications, you also need to save the user's login identity information in the same application. For example, the user logged on to page 1, but also mentioned that each client request is a separate connection, when the customer visited page 2 again, how to tell the Web server, the customer has just logged in? There is a convention between the browser and the server: Use cookie technology to maintain the state of the app. A cookie is a string that can be set by a Web server and can be saved in a browser. As shown, when the browser accesses page 1 o'clock, the Web server sets a cookie and returns the cookie and page 11 to the browser, which is saved after the browser receives the cookie, and when it accesses page 2, the cookie is also taken. When the Web server receives the request, it can read the value of the cookie, and it can judge and restore some users ' information status according to the content of the cookie value.

Cookie composition

Cookies are made up of names, content, action paths, scopes, protocols, lifetimes, and a HttpOnly attribute, which is important if you set the HttpOnly attribute in the cookie, then the JS script ( Document.cookie) will not be able to read the cookie information, so as to prevent XSS attacks to a certain extent, about XSS can see my previous article--xss attack and defense. The jsessionid of the Tomcat server settings is HttpOnly.
The cookie is encapsulated in Java EE, which corresponds to the following class:

Java.lang.Object  |  +--Javax.servlet.http.Cookie

The class can set the cookie name, content, action path, scope, protocol, life cycle, but cannot set the HttpOnly property, do not know what to do this is what to consider, if we do not want to set HttpOnly cookie, we can be processed by the response header:

[Java]View Plaincopy

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

Cookie Scope
The scope of the test cookie needs to get several domain names, modify the C:\Windows\System32\drivers\etc\hosts file, map the native IP to four domain names, as follows:

[HTML]View Plaincopy

1. 127.0.0.1 web1.ghsau.com
2. 127.0.0.1 web2.ghsau.com
4. 127.0.0.1 web1.com
5. 127.0.0.1 web2.com

The first two are 2-level domain names (ghsau.com), 3-level domain names (web1, web2) are different, the latter two are 2-level domain names. Then we write two JSPs, one for setting cookies and the other for displaying cookies.
SETCOOKIE.JSP:

[HTML]View Plaincopy

1. <%@ page  Language= "java"  contenttype= "text/html; charset=utf-8"  pageencoding= "utf-8"%>  
2. <%  
3.      Cookie cookie = new cookie ("Test_key ", " Test_value ");   
4.     cookie.setpath ("/");   
5. //  cookie.setdomain (". ghsau.com");   
6.      response.addcookie (cookie);   
7. %>  

SHOWCOOKIE.JSP:

[HTML]View Plaincopy

2. <%@ page language="java" contenttype="text/html; Charset=utf-8 " pageencoding=" utf-8 "%>
4. <%
6. Output cookies, filter out Jsessionid
8. cookie[] cookies = request.getcookies ();
10. if (cookie = null)
12. for (Cookie cookie:cookies) {
14. if (Cookie.getname (). Equals ("Jsessionid")) continue;
16. Out.println (Cookie.getname () + "-" + cookie.getvalue ());
18. }
20. %>

        put these two JSP into the application, deploy to the server, start the server, we can access through the domain name.
        test one, first access HTTP.// web1.ghsau.com:8080 /webssoauth/ setcookie.jsp, after setting the cookie, Access HTTP.// web1.ghsau.com:8080 /webssoauth/showcookie.jsp, page output test_key=test_ Value, when we visit http./ web2.ghsau.com:8080 /webssoauth/showcookie.jsp and find that the page has no output, we conclude that cookie the scope is the current domain name by default.
        test two, setcookie.jsp fifth comments open, in order to access the above, we found http:// web2. The http:// web1 is output in Ghsau . com:8080 /webssoauth/showcookie.jsp. Ghsau the cookie set in . com:8080 /webssoauth/setcookie.jsp, we conclude that cookie scope is a parent domain name, all child domain names can get the cookie , which is the key to implementing cross-domain SSO. Then some friends may think that I set the cookie scope to the top-level domain name (. com,. net), is not the Web site with the top-level domain will be able to obtain the cookie? This sets the cookie, the browser is not stored, the invalid cookie.

Test three, modify setcookie.jsp fifth line of code for Cookie.setdomain (". web2.com"), first access http://web1. com:8080/webssoauth/ setcookie.jsp, after setting the cookie, we visit HTTP:/web2. com:8080/webssoauth/ Showcookie.jsp, found that the page has no output, we conclude that thecookie cannot be set across a two-level domain name .

Cookie Security

The data in the cookie usually contains the user's privacy data, first of all to ensure the confidentiality of the data, and secondly to ensure that the data can not be forged or tampered with, based on these two points, we usually need to encrypt the cookie content, encryption generally using symmetric encryption (single key, such as DES) or asymmetric encryption ( A pair of keys, such as RSA), the key needs to be kept in a secure place on the server side so that no one can decrypt the data or falsify or tamper with the data when they do not know the key. Also, as mentioned above, important cookie data needs to be set to HttpOnly, to avoid cross-site scripting to get your cookie, to ensure the security of cookies on the browser side. And we can set cookies to be used only for secure protocol (HTTPS), Java EE can be set by the cookie class SetSecure (Boolean flag), after setting, the cookie will only be sent under HTTPS, and no longer sent under HTTP , the security of the cookie on the server side is guaranteed, the server HTTPS setting can refer to this article.