> 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-5.md).

# Lab 5

Another scenario in comparison to Lab 4, is that instead of having a pool of CRSF tokens, they don't even have a pool and instead just checks if the CRSFkey matches the CRSF body. 

#### Why this is weak

The server never generates or stores the token. It just trusts that if both values match, it must be legitimate. But the attacker can just **make up any value**:

```
csrf cookie = "abc123"
csrf body   = "abc123"
```

They match → server accepts it → no need to steal anything.

<figure><img src="/files/lgtjHlLHTIwiLPgwOkAq" alt=""><figcaption></figcaption></figure>

We see that it uses the same crsf cookie and the same crsf body. This means we just need to have the crsf in both sections the same. Quite simple fix

<figure><img src="/files/2nzCcuo03vValXUtrONl" alt=""><figcaption></figcaption></figure>

1. Victim visits your exploit page

2. img fires → server responds with Set-Cookie: csrf=FAKE123

3. Browser stores csrf=FAKE123

4. onerror fires → form submits immediately using FAKE123

5. Lab solved

6. img fires search request with CRLF injection → plants csrf=FAKE123 into victim's browser → overwrites their real csrf cookie

7. form submits with csrf=FAKE123 in body

8. server checks: cookie csrf = FAKE123 ← you planted this body csrf = FAKE123 ← you put this in form → MATCH → accepted