Cookie

A Cookie on a computer is a text file stored in the browser’s directory that takes effect in RAM while the browser is running (such Cookies are called Session Cookies). Once a user is pushed from that website or server, Cookies can be stored on the user’s local hard disk (called Persistent Cookies).

  • Timeliness:

    • Classification: Persistent Cookie, non-persistent Cookie

      • Non-persistent cookies are stored in memory, that is, their life cycle is basically the same as that of app. After app is closed, cookies are lost.
      • Persistent cookies are stored on the local disk and will not be lost after the app is closed.

    • If we want to use the Cookie persistence policy, we can mentally refer to the non-persistence policy, just change the storage mode:

      A: The cookie is extracted from the response by the response interceptor and saved locally, and the cookie is extracted from the response by the request interceptor and added to the request.

      B: Customize the CookieJar, save the cookie locally in saveFromResponse() and fetch the cookie locally in loadForRequest().

  • Restrictions: Cookies must be set before the content of the HTML file is output. Different browsers treat cookies differently. If the client user disables cookies, cookies cannot be set. On the client, a browser can create a maximum of 300 cookies, and each Cookie cannot exceed 4KB. Each Web site can set a maximum of 20 cookies.

  • Execution process:

    A: The client sends an HTTP request to the server.

    B: After receiving the request from the client, the server sends an HTTP response to the client. This response header contains the set-cookie header.

    C: The second request made by the client (if the server requires us to bring a Cookie, we need to retrieve the Cookie at step B and send the second request as the request header) provides information that the server can use to uniquely identify the client. At this point, the server can also determine whether cookies are enabled on the client. Although it is possible for a user to suddenly disable the use of cookies during interaction with an application, this is unlikely and can be ignored.

Session

Sessions are for the server. Session means that the server adds the client connection flag when establishing a connection with the client, which will eventually be converted into a temporary Cookie by the server (Apache, Tomcat, JBoss) and sent to the client. When the client makes the first request, the server will check whether it carries the Session (temporary Cookie). If it does not, it will add the Session. If it does, it will take out the Session to do relevant operations.

  • The necessity of session generation: Cookies exist in the client, and their storage size is limited. The most important thing is that users can see them and modify them at will, which is very insecure.

Token

Token is the authentication method of user identity, also called Token.

  • The simplest token components:

    • A unique user identity identifies a UID
    • Timestamp time of the current time
    • Signature sign: The first few bits of the token + salt are hashed into a long hexadecimal string
      • Objective: To prevent malicious third parties from stitching token request servers.
    • (Constant parameter)
      • Objective: To avoid multiple library searches.

  • Application Scenarios:

    • After the user logs in/registers for the first time, the server generates a token value. The token value is saved in the server (in the database) and then returned to the client.

    • After obtaining the token value, the client saves the token value locally.

    • When the client sends another network request (usually not a login request), it sends the token value in a parameter to the server.

    • After receiving the request from the client, the server retrieves the token value and compares it with the token value stored locally (in the database).

      • Case 1: If the two tokens have the same value, the user has logged in successfully and is in the login state.

      • Case 2: If the token value is not displayed, the login fails.

      • Case 3: If the two tokens are different, the original login information is invalid and the user needs to log in again.

The difference between cookies and sessions

  • Cookies are stored in the browser in the form of key-value pairs and can be used for user authentication. The storage upper limit is generally 4K. Because data is stored in the browser, it is easy to be exploited by other malicious programs. Therefore, data security is not high.
  • Session stores the user’s Session information on the server. The key value is a randomly generated string and the value is the content of the Session. The key value corresponding to each user is saved to the browser depending on the cookie. The amount of data that can be stored is larger than the cookie; Data security is relatively high because information is stored on the server and cannot be easily exploited by malicious programs.

The difference between Token and Session

  • Token is more secure than session authentication because each request is signed and protects against listening and replay attacks, whereas session relies on the link layer to secure communication.

  • Session is an HTTP storage mechanism designed to provide a persistence mechanism for stateless HTTP. Session authentication is simply a means of storing User information in a Session, which is considered safe due to the unpredictability of siDs.

  • Tokens, if referred to as OAuth tokens or similar mechanisms, provide authentication and authorization, authentication for the user and authorization for the App. The goal is to give an App access to a user’s information. The Token here is unique and cannot be transferred to other apps or other users.

  • Simply put, if your user data may need to be shared with a third party, or allow the third party to call the API, use Token. If it’s always just your own website, your own App, it doesn’t matter what you use.

  • Token is a token, for example, when you authorize (log in) a program, it is a basis to judge whether you have authorized the software. Cookie is written in a TXT file on the client, which includes your login information and so on, so that the next time you log in a website, it will automatically call the cookie automatic login user name; The session is similar to a cookie, except that the session is a file written on the server side, and you need to write a cookie file on the client side, but the file contains your browser number. The Session status is stored on the server, and the client has only the Session ID. The Token state is stored on the client.

Session Security

The root cause of Session insecurity

  • Hijacking issues (Cookie and URL parameters) caused by session delivery mechanisms. As long as there is a network there will be hijackings.
  • Fixed session.

Session data is stored on the server, so how does the server maintain the Session? Or how do you find specific users?

There are two ways to pass: cookies and URL parameters.

There is a danger when it comes to passing, and this danger is magnified in PHP.

Use cookies only to store Session ids

Session IDS can be passed using cookies and URL parameters. Cookies are more secure, and the URL is exposed more frequently. If cookies are not disabled, only cookies should be passed. Php.ini provides the session.use_only_cookies directive to enforce security.

Protect your cookies

Cookies themselves are not secure, so methods to improve Cookie security also apply to sessions. The key is HttpOnly (JavaScript is not allowed to read), and if the site supports Https, then configure cookies to be transmitted only over Https.

The expiration time of the Cookie is consistent with that of the Session

  • The lifetime of a Session is variable, and the Session file modification time is updated as soon as the Session is initialized. In other words, set the GC time to expire in 2 hours, but as long as the user keeps the Session updated (such as refreshing the page) every 2 hours, the Session will always exist.
  • After GC expires, PHP controls the deletion of Session files, but not every time expired files are deleted, so you can’t rely on it, but you can implement this mechanism by customizing the Session manager.

The Session GC cannot be relied upon, so you can indirectly set the Cookie’s expiration time (session.cookie_lifetime directive) to be equal to the GC time, so that once the Cookie expires, The same is true for the Session (although the file corresponding to the Session is not deleted, if the attacker knows the Session ID, it still poses a security problem).

Regenerate the Session ID

If an attacker has hijacked your Session ID and you don’t know it, it is recommended to reset the Session ID frequently for security purposes (e.g. using the session_regenerate_id() function irregularly). In this case, the attacker can obtain the old Session ID (assuming that the attacker cannot obtain the new Session ID), and therefore cannot obtain Session data. However, this is not entirely valid (because attackers have a way to hijack your Session ID).

A more effective approach would be to ask the user to re-enter the password for authentication when performing higher-level functions (such as e-commerce checkout) (obtaining the password is another attack). This is the most effective protection from an application layer perspective.

Session fixation

Two meanings:

  • As long as you have the correct Session ID, no matter what device you originate the request from, the server program verifies that the corresponding Session information is correct.

  • If the client forges a Session ID and the PHP process sees that the Session ID does not exist, the Session ID will be initialized. Such a mechanism may cause attacks.

    • Forgery consists of two parts:

      • The Session ID does not exist on the server itself

      • The format of the Session ID value can also be wrong

Closing the session correctly

Closing a session involves three aspects:

  • Cookies that pass the Session ID should be deleted
  • The Session file should be deleted
  • Session global variables should also be cleared in the PHP process

Data source

www.jianshu.com/p/bd1be47a1…

Juejin. Cn/post / 684490…

www.jianshu.com/p/c4b32eb24…