Cookies && Session && tokens

The origin of the cookie:
HTTP itself is a stateless request/response protocol. The server receives a request from a client and returns a response after processing. However, in this process, the server has little information to determine which client (user) sent the request, and can not record the order of the user requests.
Cookies are the best way to identify users today and to achieve a lasting session. Cookies are often used in conjunction with technologies such as USER-AGENT,REFERER,X-FORWARDED-FOR,JS to provide more detailed information to the server. In short, a cookie is a specific message that the server generates to the client in order to record the user's information, and it is stored on the client and carries a message the next time the request is sent.

Creation of Cookies
When first accessed, the server puts Set-cookie in the returned information header

Taobao, the client may have different screen sizes, we will try to adapt to the client screen, different resolution, aspect ratio, to different proportions of the size of the picture. At this point, we need the client to actively tell us its information. In Chrome we can see the value of such a cookie.
The _med parameter is the surface screen size
A section of JavaScript inside an HTML page. When the user first accesses the Taobao master station, it does not carry this information, the server can find _med to determine whether the client carries the cookie, if found not to carry, then in the response of the HTML page to add a piece of JavaScript

Session
The client flag that is saved on the server side.

Build process:
1. Generate globally Unique identifiers (SessionID)
2. Open up data storage space. It is common to create the appropriate data structure in memory, but in this case, once the system loses power, all session data will be lost, and if it is an e-commerce website, the accident will have serious consequences. However, it can also be written in a file or even stored in a database, although this will increase I/o overhead, but the session can achieve some degree of persistence, and more conducive to the sharing session;
3. Character the global unique label of the session to the client. The key to the problem is how the server sends the session's unique identity. By contacting the HTTP protocol, the data can be placed in the request line, header domain, or body, and there are generally two common ways to do this: cookies and URL rewriting.
4. The server can pass the session identifier to the client as long as the Set-cookie header is set, and each subsequent request from the client will be given this identifier, since the cookie can set the expiration time, Therefore, the cookie that normally contains session information is set to expire at 0, which means the browser process is valid for the time. As for the browser how to deal with this 0, each browser has its own scheme, but the difference is not too large (generally in the new browser window);
5. URL rewrite so-called URL rewrite, as the name implies, rewrite the URL. Imagine, before returning the page of a user request, all the URLs in the page are followed by a get parameter with the session identifier (or in the path info section, etc.) so that the user receives the response, regardless of which link or submission form is clicked, will take the session identifier again, thus realizing the conversation's retention. Readers may find this to be cumbersome, indeed, but if the client disables cookies, URL rewriting will be preferred.

Session data structure requirements: synchronous, easy to operate. So use Concurrenthashmap to store it.

Token
Token, the most important feature of tokens, is randomness, unpredictable. General hackers or software can not guess out.
Tokens are generally used in two places:

1. Prevent forms from repeating commits,
2. Anti CSRF attack (cross-site request forgery).

Both are based on the principle of the session token to achieve. When the client requests the page, the server generates a random number token, puts the token into the session, and then sends the token to the client (typically by constructing the hidden form). The next time the client submits the request, token is submitted to the server side as a single table.
Then, if applied to the "anti CSRF attack", the server side validates the token value and determines if it is equal to the token value in the session, and if it is equal, it can prove that the request is valid, not forged.
However, if you apply the "Prevent form repeat commit", after the server side first authentication is the same, the token value in session will be updated, if the user repeats the submission, the second validation judgment will fail because the token in the user submitted form has not changed, But token has changed in the server-side session.

The above session application is relatively safe, but also called cumbersome, and when multi-page multi-request, must use multi-token simultaneous generation method, so that the use of more resources, execution efficiency will be reduced. Therefore, cookies can also be used to store authentication information in place of Session tokens. For example, when a "duplicate commit" is submitted, the information that has been submitted is written to the cookie after the first commit, and when the second commit, the second commit fails because the cookie already has a record of its submission.
However, Cookie storage has a fatal weakness, and if a cookie is hijacked (an XSS attack can easily get a user cookie), then again Gameover. Hackers will directly implement CSRF attacks.

So, safe and efficient relative. Specific questions to deal with it.

In addition, in order to avoid "token but do not check" situation , added token in the session, but the service side did not verify token, there is no preventive role.

Also note that the database has changed the addition and deletion of the operation, need to add token verification, for the query operation, must not add token, to prevent the attacker through the query operation to obtain tokens for CSRF attack. However, it is not possible for an attacker to gain token, only to increase the cost of the attack.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Cookies && Session && tokens