The Cookie,session,token difference between Python Web learning notes

I. Introduction of Cookie,session,token

# all three solve the problem of stateless HTTP protocol

  session ID  or  Session token  is a piece of data that's used in Network C Ommunications (often over http) to identify A session, a series of related message exchanges. Session identifiers become necessary in cases where the communications infrastructure uses a stateless protocol such as HT Tp. For example, a buyer who visits a seller's site wants to collect a number of articles in a virtual shopping cart and then Finalize the shopping by going to the site ' s checkout page. This typically involves an ongoing communication where several webpages is requested by the client and sent back to them By the server. In such a situation, it's vital to keep track of the current state of the shopper's cart, and a session ID is one-off to achieve that goal.

A session token is a unique identifier, usually in the form of a hash generated by a hash function which is generated and s ENT from a server to a client to identify the current interaction session. The client usually stores and sends the token as an HTTP cookie and/or sends it as a parameter in GET or POST queries. The reason to use session tokens is and the client only have to handle the identifier (a small piece of data which is othe Rwise meaningless and thus presents no security risk)-all session data are stored on the server (usually in a database, T o which the client does not has direct access) linked to that identifier. There is many drawbacks of session ID and it ' s not enough to fulfill the developer requirements.^{[Vague] Many developers use other logic to identify the session}

1. Cookie mechanism

A cookie mechanism is a scheme that maintains state on the client. The use of cookies is automatically sent to the server in the background by the browser in accordance with certain principles. The browser checks all stored cookies and, if a cookie declares a scope greater than or equal to the location of the resource to be requested, sends the cookie to the server on the HTTP request header of the requesting resource.

The contents of a cookie mainly include: name, value, expiration time, path, and domain. The path together with the domain constitutes the scope of the cookie.

If you do not set an expiration time, the cookie will be closed for the duration of the browser session. This cookie for the lifetime of the browser session is referred to as a session cookie. Session cookies are generally not stored on the hard disk but are kept in memory. If the expiration time is set, the browser willsave the cookie * * * on the hard disk * *, turn it off and open the browser again. These cookies remain valid until the set expiration time is exceeded. Cookies stored on the hard disk can be shared between different browser processes, such as two IE windows. For cookies stored in memory, different browsers have different ways of handling them.

2. Session mechanism

The session mechanism is a server-side mechanism.
When a client requests a server, the server checks to see if a session ID is included in the request (called the session ID.).

• If not, then the server generates a random session and the session ID that matches it, and returns the session ID to the client.
• If so, the server finds the corresponding session in the store based on the session ID.

When the browser prohibits cookies, there are two ways to continue to transfer session ID to the server: the first: URL rewrite (commonly used), is to append the session ID directly behind the URL path. Second: The form hides the field, and the SID is written in the hidden form.

3. Token mechanism

Token is the user's way of authentication, the simplest token consists of the UID (the user's unique identity), time (timestamp of the current time), sign (signature, which is compressed into a long hexadecimal string by a hash algorithm from the first several + salts of token), Can prevent malicious third party stitching token request server).

using the Token-based authentication method, there is no need to store user login records on the server side. The approximate process is this:1. The client uses a username and password to request login 2. The serverreceives a request to verify the user name and password 3. After the verification is successful, the server will issue a token and send the token to the client. 4. The client receives the token and can store it, for example, in a Cookie or Local Storage 5. Each time a client requests a resource fromthe server, it needs token 6 that is issued by the server. The server receives the request and then verifies the Token that is in the client request and returns the requested data to the client if the validation is successful

Ii. The difference between a cookie and a session

1. The cookie data is stored on the client and the session data is placed on the server.

2, the cookie is not very safe, others can analyze the cookie stored in the local and cookie deception
Consider that security should use the session.

3. Session will be saved on the server for a certain period of time. When access is increased, it will be more likely to occupy your server's performance
In view of mitigating server performance, cookies should be used

Third, the difference between the session and token

Token security as an authentication is better than the session, because each request has a signature to prevent eavesdropping and replay attacks

The Session is an HTTP storage mechanism designed to provide a durable mechanism for stateless HTTP. Session authentication simply stores the user information in the session because the SID is not predictable and is considered safe for the moment. This is a means of authentication. However, if a user's SID is available, it is equivalent to having all the rights of that user. SIDs should not be shared with other websites or third parties.

token, if it refers to an oauth Token or similar mechanism, provides authentication and authorization, authentication is for the user, and authorization is for the app. The purpose is to give an app the right to access a user's information. The token here is unique. Can not be transferred to other apps, nor can it be transferred to other users.

Iv. vulnerabilities in the session management mechanism

There are two main vulnerabilities in the session management mechanism:1. Weak links during session token generation 2. Dealing with the weaknesses of Session tokens throughout the life cycle process

V. Weak links in the generation process 1. Tokens have a certain meaning

Some session tokens are converted directly from the user name or mailbox, or are created using some basic information. This makes it easier to build tokens.

A common token with meaning has the following information: Account username Application used to differentiate account number identifier user's last name/ name e-mail date / time stamp an increment / decrement IP address for a digital client

Tokens are also likely to pass through XOR,BASE64, convert ASCII, and so on to advanced line-coded operations, and then generate tokens.

2. Token predictable

The token can be predicted, mainly has these three aspects to cause: the implicit sequence, the time dependence, produces the numerical randomness not to be strong.

Implicit sequence: The main is the instruction card is through a simple arrangement, and then coded or hexadecimal addition and subtraction operations, as long as the basic method of guessing it, you can find the law.
Time-dependent: tokens produce different pseudo-random tokens based only on time transformations.
Randomness is not strong: The instruction card is generated by a simple linear congruence function, if the function is also public, such as the Java java.util.Random function.

Vi. the weak links in the course of life 1. Leaking tokens on the network

When a Web site, such as a non-confidential transfer session token, is likely to cause the token to be tapped. For example, use non-encrypted HTTP to communicate.

It is important to note that some Web sites, although some of the pages use HTTPS, but also some of the pages using HTTP, then the token is likely to be exposed in these HTTP communication pages.

2. Leaking tokens in the log

The main reason may be that the application uses a URL query string instead of using HttpCookie or a POST request as the transport mechanism for the token. In the Java Web, for example, the URL is followed by http://xxx.com;jsessionid=xxx, and when such a URL is written into a log or other history, the SID is easily fetched.

When a cookie is banned, it is easy to use a URL to transmit the token.

3. Session termination vulnerable to attack

Some sites, after the user exits, it clears the client's token only through commands such as Set-cookie, and the service-side token is not deleted. It is also possible that when a user exits, the application does not communicate with the server, causing the server to do nothing. These behaviors cause the user to be able to communicate with the server again when the token is submitted again.

4. Clients exposed to the risk of token hijacking

An attacker could attack a user through XSS, obtain a user's cookie, and obtain a token. Therefore, the cookie should be careful to set httponly, which can slow down the XSS attack.

Reference 1

Reference 2

The Cookie,session,token difference between Python Web learning notes