The introduction

Recently, it has been found that many WEB application systems use JWT for session management. The reason is to avoid the server to store the session, or to pursue independent control, but I do not know that using JWT for session management has huge security risks!

HTTP Session Management

Let’s start with HTTP, which is known for its q&A (one request, one response) feature. So based on THE HTTP protocol, to make a shopping website, to realize the user login, add goods to the shopping cart, and finally pay the bill. To do this, the simplest way to identify a series of actions by the same user is to send an account and password each time the user accesses the browser, so that the server knows which user is adding items to the cart and ultimately paying the bill. This would seem crude, and carrying the account and password with each request would greatly increase the risk of disclosure.

To reduce the number of times an account password is carried in a request, we introduce something called session-id. When you log into a shopping site with your account password (the first request), the server returns a session-ID after verification. You can then add items to your cart, or place final orders, and carry the session-ID with you for each subsequent request. Why does carrying session-ID identify which client’s operation? Because the server associates the account information of the client with the session-ID sent to the client, the association information between the session-ID and the account is session-data.

In the example above, session-data is stored on the server side. Session-data can also be stored on the client. According to the location of session-data storage, there are two modes: Server Side session and Client Side session.

Server Side Session

The Server Side Session pattern is the most common, as shown in the previous shopping site example. In this mode, the client (browser) stores the session-ID in local cookies. Its typical implementation is shown in the figure below:In the above figure, User A is an old User who has already established A session. His Cookies store the Session_id with the value of “AA01”, and carry this Session_id in the request. After receiving the Session_id, the server queries the corresponding data in the Session Database and uses it in the program. New User is a New User who has just started a session and does not have a Session_id in his Cookies, so the server generates a New Session_id and returns it to him with the 401 status code to tell him to redirect to the login page and log in. If the New User logs in successfully, the server will store his identity information in the Session Table and associate it with the session_ID generated at the beginning of the Session. In this way, subsequent requests will be treated as if User A was the old User.

Client Side Session

The Client Side Session mode may seem a little strange to you, but it is widely used. For example, most WEB systems that use JWT for Session management are in the Client Side Session mode. The so-called Client Side Session mode is to store the user’s session-data data in the Client, so that the server is very free. The interaction process is roughly as shown in the figure below:In the figure above, User A on the left is an old User who has established A session. His Cookies store Session_data, whose value is the basic information of the current User. The request carries Session_data, and the server parses the Session_data information after receiving the request. You know which user is making the request. The New User on the right is logging in to establish a session. After the authentication succeeds, the server generates session_data information and returns it to the client. Since the session_data data is stored on the client, to prevent tampering, the server will sign and even encrypt the generated session_data data.

Server Side VS Client Side

The principles of Server Side Session and Client Side Session have been introduced. Which one is better? Before comparing, set a baseline that is only functional and security, rather than comparing the original implementation of the two patterns.

Server Side Session

Advantages:

  1. Session data is stored on the server and does not expose related information, ensuring high security.
  2. Only the session-ID is transmitted in each request to reduce traffic overhead.
  3. The server can easily revoke the session, control the number of concurrent sessions with the account and other comprehensive session policy management.

Disadvantages:

  1. If the server is deployed in distributed mode, session-data sharing needs to be added.

Client Side Session

Advantages:

  1. Decentralized storage;

Disadvantages:

  1. Session data is stored on the client and carried in each request, increasing the risk of leakage.
  2. More data needs to be transferred per request, increasing traffic overhead;
  3. It is not convenient for the server to revoke the session to manage various session policies.

As can be seen from the above comparison, the two modes have opposite features in terms of functionality and security. The Server Side Session mode has many advantages, but why does the Client Side Session mode exist? The existence of the Client Side Session mode is reasonable, because the original implementation is simple! In Client Side Session mode, the server does not need to store session-data data in a centralized manner, nor does it need to process the search for session-data. Moreover, the server stores session-data data in a decentralized manner on the Client, and does not need to consider the distributed session-data sharing. However, the primitive simplicity of the Client Side Session mode is not important to the user, because the user only uses existing libraries and frameworks, as long as they are well supported. Therefore, the Server Side Session mode is more common than the Client Side Session mode.

What is JWT?

First, the JWT (JWE, JWS) standard is only designed as a tamper-proof token, not for session management. JSON Web Token(JWT) is an open data standard based on RFC 7519. It defines a loose and compact way to combine data and use JSON objects to transfer information between applications (jWE for information encryption and JWS for signature). The JSON object can be authenticated and verified by digital signature. Generally, JWT can use the HMAC algorithm, RSA or ECDSA public/private key to sign data. A JWT consists of a HEADER, PAYLOAD, and SIGNATURE. Link, in the format shown above.

The defect of JWT

The JWT standard design looks good, but in fact it hides a lot of security issues because of its design, as detailed below:

Reset null encryption algorithm defect

JWT supports setting the algorithm to “None”, and any Token is valid if you use the JWT library without setting this feature to be turned off. By setting the ALG field in the first header of the JWT to None and the signature field in the third header to null, the token can be authenticated successfully.

Key obfuscation attack

The two most commonly used algorithms for JWT are HMAC and RSA. HMAC (symmetric encryption algorithm) uses the same key to sign and authenticate the token. RSA (asymmetric encryption algorithm) requires two keys, encrypted with the private key to generate JWT, and then used its corresponding public key for decryption and authentication. If the public key is compromised (and many people think it can be distributed), then the algorithm RS256 is changed to HS256, that is, asymmetric encryption is downgraded to symmetric encryption. The leaked public key is then used to sign the token. After receiving the token, the backend verifies the token using the public key according to the algorithm specified in the header. In this way, the authentication succeeds.

Key brute-force cracking

If JWT uses a symmetric encryption algorithm (such as HS256), this means that the key that signs the token is also used to validate it. Because signature verification is a self-contained process, the token itself can be tested for a valid key without having to send it back to the application for verification. If the key setting is too simple, such as common words, birthday year, etc., combined with the known list of leaked passwords, the key will be quickly cracked, so that any token can be forged.

Kid specified attack

Kid is the key ID, which exists in the JWT header and is an optional field that specifies the key of the encryption algorithm. For example, if a new kid field is injected in the header and the key of HS256 algorithm is specified as 123456, a new token is generated, and the server will use the specified key 123456 to verify the token.

How can I avoid the pitfalls of JWT

In addition to key brute-force cracking, all the problems listed above are caused by the JWT standard design. If you choose to use the JWT standard, find a reliable implementation library and perform security tests. Avoid using symmetric encryption algorithms, and configure security items correctly, such as enabling the JWT header, disabling ALG to None, and disabling key degradation. But the best way to avoid it is to switch from JWT to PASeTO, a new standard that replaces JWT.

“Advantages” of JWT for session management

First, as mentioned earlier, the JWT standard was not designed for session management, and certainly not the PASETO standard (its replacement). Most of today’s Session management using JWT is actually the Client Side Session mode. In the Client Side Session mode, Session data is stored on the Client. To prevent data tampering or leakage, data stored on the Client is generally signed or encrypted. Many people use the JWT implementation library to put session data in the PAYLOAD area, generate a token, and send it to the client. If the client is a web browser, it even places the token received in localStorage through JS. All of this makes developers feel like they have everything under control, but there are a lot of bugs.

Those using JWT for session management claim the following benefits:

  1. Natural support for distributed validation;
  2. Reduce server stress under high concurrency;
  3. Flexible and easy to use;
  4. Safer, can prevent CSRF;
  5. It works better on mobile devices;
  6. Applies to users who block cookies.

​

The advantages claimed above are actually brought about by the Client Side Session mode and autonomous control of tokens. But I want to tell you that for users, all of these advantages are false propositions.

Naturally supports distributed authentication

This trait is true, but the reality is that few people really need it. Because session sharing technology is mature, existing software frameworks provide good support schemes.

Reduces server stress at high concurrency

It seems that with high concurrency, the Client Side Session mode has no server-side storage and query, which reduces server stress. However, if you do have high concurrency, you should be more concerned about the strain that business processing puts on the server than session storage and queries, which are a drop in the bucket.

Flexible and easy to use

This is a complete error, custom uses JWT for session management, requires more code configuration to handle, how flexible and easy to use?

Safer to prevent CSRF

As mentioned above, JWT has many design problems, not to mention the risk of information leakage caused by the Client Side Session mode. However, CSRF can be prevented unless you put the token in an area other than cookies, such as localStorage, and use JS to operate, which brings much greater risk.

It works even better on mobile devices

It’s been a long time since some mobile browsers didn’t support cookies, but that’s gone. Mobile development frameworks now support cookies as long as there is a decent HTTP library, so this is not a problem at all.

Applies to users who block cookies

There are users who block the use of cookies to avoid being tracked. But setting up a session requires login authentication, so users who choose to block cookies understand why I can’t log in. For users who really want to avoid tracking, not only cookies will be blocked, but any client storage will be blocked. In Client Side Session mode, Session information cannot be saved.

If you prefer the Client Side Session mode and really feel that the Client Side Session mode meets your needs, you can simply implement the Client Side Session mode supported by the server framework without using JWT.

The right way to manage HTTP sessions

For secure sessions, HTTPS is used to ensure the security of the transport channel. Then the implementation of Server Side Session mode is used. For example, cookies in web browsers store random identifiers, namely session-ID, which is paired with session-data stored on the Server Side. If you need to hold a session for longer, add a long remember Me ID instead of extending the session-ID arbitrarily.

JWT Session management can be extended to avoid the drawbacks of Client Side Session mode. For example, if the session is revoked, the server can add the issued token to the blacklist mechanism, or record the issued token, set the validity period, and compare each request. So the question is, is this still Client Side Session?

supplement

Some friends say that JWT is very simple to implement single sign-on, but I have no answer to this question. The token authentication can be implemented by configuring the same key for multiple systems. Yes, this is actually the advantage of the Client Side Session mode, which can achieve “single sign-on” effect in certain scenarios. This is impossible to achieve in most scenarios, because you first need software systems developed by different companies to use JWT for session management, and then trust each other to share the same key (which is extremely insecure). The mainstream protocol for single sign-on is OIDC or OAuth2, and the older protocols are SAML or CAS.

A friend asked, since JWT is not designed for session management, what should it be used for? JWT applies to single-use tokens, that is, short validity, one-use. Such as short-acting one-time links used in password retrieval emails, or file downloads.

reference

[EB/OL]. [1] cryto.net/~joepie91/b… 2021-05-04 [2] paseto [EB/OL]. Github.com/paragonie/p… /. The 2021-05-04 [3] [EB/OL]. Paragonie.com/blog/2017/0… 2021-05-04 [4] [EB/OL]. Geekkeen. Making. IO/HTTP – cookies… 2021-05-04 [5] [EB/OL]. Blog. By24. Cn/archives/ab… . 2021-05-04