Deep Cookie resolution and deep cookie resolution

[Switch] Cookie deep resolution and cookie deep resolution

Cookie Introduction

As we all know, the Web protocol (HTTP) is a stateless protocol (HTTP1.0 ). A Web application consists of multiple Web pages, each of which is defined by a unique URL. The user enters the URL of the page in the address bar of the browser, and the browser sends a request to the Web Server. For example, the browser sends two requests to the Web server and applies for two pages. The two page requests use two separate HTTP connections. The so-called stateless protocol is shown here. the browser and the Web server will close the connection channel after the first request is completed, and re-establish the connection at the second request. The Web server does not distinguish the client from which the request comes from. All requests are connected separately. This method is much different from the traditional (Client/Server) C/S structure. In such an application, the Client and Server will establish a dedicated connection channel for a long time. It is precisely because of stateless features that each connection resource can be quickly reused by other clients that a Web server can serve thousands of clients at the same time.

However, our common applications are stateful. You do not need to mention SSO between different applications. In the same application, you also need to save your login identity information. For example, the user logged on when accessing page 1, but as mentioned earlier, each client request is a separate connection. When the customer accesses page 2 again, how can I tell the Web server that the customer has logged on just now? There is an agreement between the browser and the server: The cookie technology is used to maintain the application status. Cookie is a string that can be set by the Web server and can be saved in the browser. As shown in, when the browser accesses page 1, the web server sets a cookie and returns the cookie together with page 1 to the browser. After the browser receives the cookie, it will save it, when it accesses page 2, it will also bring this cookie. When the Web server receives a request, it can also read the cookie value, you can determine and restore the Information Status of some users based on the content of the cookie value.

Cookie Composition

Cookie is composed of the name, content, Action path, scope, protocol, and lifecycle. In addition, there is an HttpOnly attribute. The HttpOnly attribute is very important. If you set the HttpOnly attribute in the cookie, then, use the js script (document. cookie) will not be able to read the cookie information, which can prevent XSS attacks to a certain extent. For more information about XSS, see my previous article-XSS attacks and defense. The JSESSIONID set by the Tomcat server is HttpOnly.

Java EE encapsulates cookies and corresponds to the following class:

java.lang.Object  |  +--javax.servlet.http.Cookie

This class can be used to set the cookie name, content, Action path, scope, protocol, and lifecycle. but it cannot be used to set the HttpOnly attribute, if you need to set HttpOnly cookies, you can use the response header to process them:

 

Cookie Scope
To test the Cookie scope, You need to obtain several domain names, modify the C: \ Windows \ System32 \ drivers \ etc \ hosts file, and map the local ip address to four domain names, as shown below:

[Html]View plain copy print?

    127.0.0.1 web1.ghsau.com      127.0.0.1 web2.ghsau.com            127.0.0.1 web1.com      127.0.0.1 web2.com  

 

The first two are two levels of domain names (ghsau.com) are the same, the third level domain names (web1, web2) are different, and the last two are two levels of domain names are different. Then we will write two more JSPs, one for setting the Cookie and the other for displaying the Cookie.
SetCookie. jsp:

[Html]View plain copy print?

    <%@ page language="java" contentType="text/html; charset=utf-8" pageEncoding="utf-8"%>      <%          Cookie cookie = new Cookie("test_key", "test_value");          cookie.setPath("/");      //  cookie.setDomain(".ghsau.com");          response.addCookie(cookie);      %>  

 

ShowCookie. jsp:

[Html]View plain copy print?

<% @ Page language = "java" contentType = "text/html; charset = UTF-8" pageEncoding = "UTF-8" %> <% // output cookies, filter out JSESSIONID Cookie [] cookies = request. getCookies (); if (cookies! = Null) for (Cookie cookie: cookie) {if (Cookie. getName (). equals ("JSESSIONID") continue; out. println (cookie. getName () + "-" + cookie. getValue () ;}%>

 

After placing the Two JSPs into the application, deploy them to the server and start the server, we can access them through the domain name.
Test 1: first access http ://Web1.ghsau.com: 8080/WebSSOAuth/SetCookie. jsp. After setting the cookie, access http ://Web1.ghsau.com: 8080/WebSSOAuth/ShowCookie. jsp, the page outputs test_key = test_value, then we access http ://Web2.ghsau.com: 8080/WebSSOAuth/ShowCookie. jsp. When no page is output, we conclude that the cookie is the current domain name by default.
Test 2: Open the comment on the fifth line of SetCookie. jsp, and access it in sequence. We found that http ://Web2.Ghsau. Com: 8080/WebSSOAuth/ShowCookie. jsp outputs http ://Web1.Ghsau. Com: 8080/WebSSOAuth/SetCookie. the cookie set in jsp, then we conclude that when the cookie scope is a parent-level domain name, all child-level domain names can obtain the cookie, which is also the key to implementing cross-subdomain SSO. At this time, some friends may think that if I set the cookie scope to top-level domain names (. com,. net), will all websites with this top-level domain name be able to get the cookie? The cookie set in this way is not stored by the browser and is invalid.

Test 3: Modify the SetCookie. jsp code to cookie. setDomain (".web2.com"), first access http ://Web1. Com: 8080/WebSSOAuth/SetCookie. jsp. After setting the cookie, we access http ://Web2. Com: 8080/WebSSOAuth/ShowCookie. jsp: when no page is output, we conclude that cookie cannot be set across second-level domain names.

Cookie Security

Cookie data usually contains the user's private data. First, we must ensure the confidentiality of the data. Second, we must ensure that the data cannot be forged or tampered with. Based on these two points, we usually need to encrypt the cookie content. The encryption method generally uses symmetric encryption (single key, such as DES) or asymmetric encryption (one key, such as RSA ), the key must be stored in a secure place on the server. In this way, when others do not know the key, they cannot decrypt the data or forge or tamper with the data. In addition, as mentioned above, important cookie data must be set to HttpOnly to avoid cross-site scripting to obtain your cookie and ensure the security of the cookie on the browser side. In addition, we can set the cookie to act only on the secure protocol (https). In Java EE, we can set it through setSecure (boolean flag) of the Cookie class, this cookie is only sent under https instead of http. This ensures the security of the cookie on the server side. For more information about server https settings, see this article.

This article is from: Gao Shuang | Coder. The original Article address is http://blog.csdn.net/ghsau/article/details/20466351. For more information, see.