> For the complete documentation index, see [llms.txt](https://simon-6.gitbook.io/simoncyber/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://simon-6.gitbook.io/simoncyber/portswigger-web-academy/crsf/lab-3.md).

# Lab 3

<figure><img src="/files/0Hn3qVrqNSPTgyVrXxuh" alt=""><figcaption></figcaption></figure>

The server keeps a pool of valid tokens:

```
valid tokens: [abc123, xyz789, def456, ...]
```

It only checks **"is this token in our pool?"** — not **"does this token belong to THIS user's session?"**

```
1. Attacker creates their own account on the site
2. Attacker loads the form → gets their own valid token: abc123
3. Attacker puts their token into the forged CSRF form
4. Victim visits the forged page
5. Form submits with attacker's token
6. Server checks → abc123 is in the pool → valid → accepted

In other words:
token must exist AND
token must match THIS user's session
```

### Solving It

* Open Burp's browser and log in to your account. Submit the "Update email" form, and intercept the resulting request.
* Make a note of the value of the CSRF token, then drop the request.
* Open a private/incognito browser window, log in to your other account, and send the update email request into Burp Repeater.
* Observe that if you swap the CSRF token with the value from the other account, then the request is accepted.
* Create and host a proof of concept exploit as described in the solution to the CSRF vulnerability with no defenses lab. Note that the CSRF tokens are single-use, so you'll need to include a fresh one.
* Change the email address in your exploit so that it doesn't match your own.
* Store the exploit, then click "Deliver to victim" to solve the lab.