> For the complete documentation index, see [llms.txt](https://ganesha-hk.gitbook.io/cybersecurity-writeups/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ganesha-hk.gitbook.io/cybersecurity-writeups/port-swigger-jwt-labs/lab-7.md).

# lab-7

## JWT Authentication Bypass via Algorithm Confusion

**Difficulty:** Expert

### Lab Description

This lab uses a JWT-based mechanism for handling sessions. It uses a robust RSA key pair to sign and verify tokens. However, due to implementation flaws, this mechanism is vulnerable to algorithm confusion attacks.

**Objective:** Obtain the server's public key from a standard endpoint, use it to sign a modified session token that gives you access to the admin panel at `/admin`, then delete the user `carlos`.

**Credentials:** `wiener:peter`

### Root Cause

The application was vulnerable to an **algorithm confusion attack** due to improper use of a generic JWT verification function. The JWT library provided a single method such as `verify(token, key)` that determines the verification algorithm from the user-controlled `alg` header instead of using a fixed, server-configured algorithm.

The application was designed to use **RS256**, where the server signs JWTs with its RSA private key and verifies them using the corresponding public key. During verification, the developer always passed the server's public key to the generic verification function:

```
publicKey = serverPublicKey
verify(token, publicKey)
```

An attacker modified the JWT header and changed `alg` from `RS256` to `HS256`, then generated a **new HS256 signature** using the server's publicly available RSA public key as the HMAC secret.

When the modified JWT reached the server, the JWT library read the attacker-controlled `alg` header and interpreted the public key as an HMAC secret instead of an RSA public key. Since both the attacker and the server used the **same public key bytes** as the HMAC secret, the generated signature matched the server's verification result. The server accepted the forged JWT and trusted the attacker-controlled claims.

### Exploitation

1. Start the login flow and capture all requests in Burp Suite.
2. Navigate to the `/jwks.json` endpoint and copy the server's public key.
3. Go to the **JWT Editor Keys** tab and click **New RSA Key**. In the dialog, paste the JWK obtained from `/jwks.json`.
4. Select the **PEM** radio button and copy the resulting PEM key.
5. Go to the **Decoder** tab and Base64-encode the PEM key.
6. Go back to **JWT Editor Keys** and click **New Symmetric Key**.
7. Click **Generate** to create a new key in JWK format.
8. Replace the generated value for the `k` parameter with the Base64-encoded PEM key copied in step 5. Save the key.
9. In Repeater, update `"sub"` to `"administrator"` and change the URL to `GET /admin`.
10. Sign the JWT using the new saved HS256 key.
11. Send the request and open the response in the browser.
12. Click **Delete carlos** in the browser and capture the resulting request.
13. Find `GET /admin/delete?username=carlos`, update `"sub"` to `"administrator"`, sign with the HS256 key again, and send.
14. The user `carlos` is deleted.

### Lesson Learned

Applications should never trust the JWT `alg` header supplied by the client to determine which signature verification algorithm to use. The expected signing algorithm must be configured and enforced on the server side.

When using asymmetric algorithms such as RS256, the server must always verify JWTs using the RSA public key and must never interpret that public key as an HMAC secret. Mixing symmetric (HS256) and asymmetric (RS256) algorithms through a generic verification function creates algorithm confusion vulnerabilities.

Developers should explicitly restrict accepted algorithms, reject unexpected `alg` values, and avoid generic verification methods that automatically select the algorithm from the JWT header.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://ganesha-hk.gitbook.io/cybersecurity-writeups/port-swigger-jwt-labs/lab-7.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.