Shulou(Shulou.com)05/31 Report--

How to steal JWT from localStorage through XSS? for this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

Words written in the front

I have come across some insecure implementations of JSON Web tokens (JWT) that eventually lead to the hacking of the target Web application. In some scenarios, attackers can take advantage of misconfiguration and XSS vulnerabilities to steal administrator tokens, or forge user protocols during user registration and create standard user accounts with administrator privileges.

JWT is different from traditional Cookie. Although they are similar, many people mistakenly believe that an attacker cannot attack JWT in this way.

We will give a brief introduction to JWT and the difference between JWT and traditional Cookie, demonstrate how to steal JWT, and finally give the corresponding security solution.

What is the JSON Web token?

In short, JWT, or JSON Web tokens, can help users authenticate the system quickly and easily (usually using open source libraries to implement authentication mechanisms). JWT consists of the following three parts, each of which is composed of "." Separation:

Header.payload.signature

Header indicates the hashing algorithm used, payload contains user-related information (such as roles and access rights, etc.), and signature is used to ensure message integrity.

In most configurations, when the user provides valid credentials, the token is set in the HTTP header and used for subsequent identity authorization, similar to the standard session Cookie.

In recent years, the community has exposed a lot of JWT-related vulnerabilities, and many technical articles have discussed these vulnerabilities, such as algorithm attacks and power enhancement through Payload tampering and so on. So in this article, I don't intend to talk too much about the JWT architecture and previous vulnerabilities.

How to restore traditional Cookie and JWT

The purpose of Cookie is that it can provide relevant state information to a stateful protocol, such as HTTP. To take a simple example, session Cookie can be used to track authenticated user sessions on a Web application. To achieve this, the record of the session must exist on both the server side and the client side.

From a JWT perspective, tokens can be stateless. That is, session records are not stored on the server side. Instead, each request sent to the server contains a user token, and the server verifies the user's identity permissions based on the token information.

Both Cookie and JWT follow a similar flow of events to request and receive session tokens, and when the user provides valid identity credentials, the server returns a response containing the session token. The difference is that Cookie is set using the SET-COOKIE command, but JWT is usually set in the AUTHORIZATION header.

Where are they stored?

We summarize with the default configuration:

LocalStorage / sessionStorage

By default, the Web browser container is almost the same. After you close the browser, the localStorage remains the same, and the sessionStorage only lasts until the browser is closed. Therefore, it can only be read on the client side, not on the server side, and can only be read through JavaScript.

Cookie

Our goal is to have the sent information read and validated on the server side. If the correct protection mechanism is configured, it will be difficult for malicious JavaScript to read this data.

Traditional Cookie protection

Generally speaking, an attacker will attack the authentication Cookie through XSS vulnerabilities, then attempt to hijack the target's administrator session, and eventually open the "door" to the target network system by attacking the Web server containing the vulnerability.

We can set the Header parameter for the data stored in the Cookie container. In addition to solving the underlying XSS problem, there are HttpOnly, secure, path and domain flags that provide different levels of security protection. Then the JWT is stored in localStorage. This is like storing the password in a text file.

How to steal JWT in localStorage through XSS vulnerabilities

In a recent study, I discovered a storage XSS vulnerability, and the target application happened to use JWT as the implementation of the authentication mechanism. After the Payload setting is successful, the JWT of any user who visits the Web page will be sent to the attacker.

At first, I couldn't get JWT through XSS. Mainly because each JWT stores a unique identifier / key, it cannot be called without knowing this information. For example, a typical way to display a standard Cookie (unprotected mechanism) in an JavaScript warning box is as follows:

Alert ([xss_clean])

Because the data in localStorage is stored in an array, it cannot be called or read through similar methods:

Alert (localStorage)

However, we can get every object stored in localStorage or sessionStorage by using the getItem () function:

Alert (localStorage.getItem ('key')) reference sample: alert (localStorage.getItem (' ServiceProvider.kdciaasdkfaeanfaegfpe23.username@company.com.accessToken'))

As shown in the figure above, we also need to figure out what the unique identifier "key" is:

I guess some people may already want to crack it violently, or write a JavaScript script to iterate over every object in localStorage. Here we can do this using JSON.Stringify, which converts what is stored in localStorage into a string and bypasses this obstacle:

Alert (JSON.stringify (localStorage))

Here is the complete PoC for stealing JWT using XSS:

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.