Day 9: CSRF Where the Token Is Duplicated in the Cookie

Hello hunters,

Today, I solved another CSRF lab without looking at any solutions.

Well… except for the encoding thing. But that doesn't count, right?

Anyway.

This lab is similar to the previous one I wrote about. If you read my last story, you know the struggle. This time was different, though. This time, I actually knew what I was looking for.

The Lab

The application has an email change functionality. Vulnerable.

I started the lab, logged in using the given credentials, and captured the request that changes the email.

By looking at the request, I could see the application is using a double CSRF token. But here's the interesting part — both tokens have the same value.

None
  • One lives in the cookie.
  • The other lives in the request parameter.

The Testing

First, I wanted to check if they are tied together. So I changed the last letter of the request parameter CSRF token.

email=wiener12%40normal-user.net&csrf=P6QvWNJ5cXNAhhLpstoS864RXeUtSjJ1

(Changed the last letter.)

And… it failed. Expected.

None

Then I tried something else. I changed the cookie CSRF token instead — same change, just the last letter.

Cookie: session=12HBtLELka0L1PmCglwYMRcHgyyREVWy; csrf=P6QvWNJ5cXNAhhLpstoS864RXeUtSjJ1

Now both tokens had the same changed value. Not what the server gave me. But both matched each other.

And it worked.

None

The Realization

The server doesn't care what the actual value is.

It just checks that the cookie CSRF token and the request parameter CSRF token are equal to each other. That's it. No session validation. No extra checks.

Just: "Are these two strings the same?"

Yes? Come in.

No? Go away.

The Exploit

I ran straight to write my PoC. Pasted it in the exploit hosting page.

"Invalid CSRF token"

What.

Then it hit me.

My PoC only included the request parameter token. The cookie token? Missing. Because the browser sends cookies automatically… Wait, no. The victim's browser would send their cookies. Not my injected one.

I need to inject the CSRF token into the victim's cookie section. Just like the last lab.

So I used the search parameter again. Same trick. CRLF injection.

<img src="https://0aa9000e04d34b0e804b03e20094005a.web-security-academy.net/?search=hunt%0d%0aSet-Cookie:%20csrf=P6QvWNJ5cXNAhhLpstoS864RXeUtSjJ1%3b%20SameSite=None" onerror="document.forms[0].submit()">

The %0d%0a does its magic. The server thinks it's a new header. The cookie gets injected. The form submits. Both CSRF tokens match.

Lab solved.

None
None

What I Learned

This lab took me less time than the last one. Not because it was easier. But because I made mistakes before. Lots of them.

And those mistakes taught me what to look for.

The vulnerability here is simple — the server only checks if two values are equal. It doesn't check if those values are valid. So if I can make both values the same — even if they are both wrong — the server accepts it.

Closing

I have covered some other labs too. Will write about them in the next story.

Till then, keep making mistakes.

Because mistakes make you perfect.

Or at least… less wrong than before.