First I did some CSRF labs as right now I am studying CSRF.

Lab 1: Validation depends on token being present

This lab is based on "Validation of CSRF token depends on token being present". Right now I am learning from PortSwigger.

As per PortSwigger, some applications correctly validate the token when it is present but skip the validation if the token is omitted.

In this situation, the attacker can remove the entire parameter containing the token (not just its value) to bypass the validation and deliver a CSRF attack:

POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 25
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm
email=pwned@evil-user.net

Okay, that being said, I entered the lab and logged in using the given credentials and changed email. Then I captured the request, sent it to repeater, and removed all unwanted parameters from header.

None

Then I copied the request header and went to make CSRF PoC.

I copied the exploit and pasted it in the HTML hosting page which is given in the lab.

<!DOCTYPE html>
<html lang="en">
<body>
<h1>Form CSRF PoC</h1>
<form method="POST" action="https://0ada0076038f775e81d74df200ec0097.web-security-academy.net/my-account/change-email">
<input type="hidden" name="email" value="pavan4@normal-usr.net">
<input type="submit" value="Submit Request">
</form>
</body>
</html>

Issue I faced: In this exploit, the email parameter was broken. After name=" the rest of the code went to a new line which threw an error saying "email parameter is missing". So make sure the code is written perfectly. Even a small tiny mistake can lead to failure.

Okay, after this I just stored the code and delivered it to the victim. The lab was solved successfully.

None

One thing I wanted to check

Instead of removing the CSRF completely from the header, what if I change its value?

None

As you can see, it threw a 400 Bad Request error. That means if CSRF is present, it will validate it. But if I remove it completely, it will not check whether CSRF is present or not.

Lab 2: CSRF token is not tied to user session

As per PortSwigger, some applications do not validate that the token belongs to the same session as the user who is making the request. Instead, the application maintains a global pool of tokens that it has issued and accepts any token that appears in this pool.

In this situation, the attacker can log in to the application using their own account, obtain a valid token, and then feed that token to the victim user in their CSRF attack.

That means we will use our own valid CSRF token to perform CSRF attack on the victim.

And as I suspected, the lab provides us two accounts to perform the attack. But still this lab is a little confusing. I spent 2 hours trying to figure things out and was still confused. I watched some YouTube solutions and after another half hour I just followed the solution.

What I did

There are two accounts:

  • wiener : peter
  • carlos : montoya

I considered it like this: wiener is victim, carlos is attacker.

I logged into both accounts and captured requests in Burp Suite. Then I changed email in wiener's account and captured that request too.

Something new I found (this information was new for me)

In this lab, when you log in, the "my account" page loads and on that same page the email change functionality is also available.

If you capture the request in Burp Suite and look at the response source code, you will see the CSRF token is provided in the response. That CSRF token will be used when you submit the form to change email.

And one more thing: Every time the page loads, a new CSRF token is given in the response. That means you cannot use the same token twice.

Moving forward

I had two requests in repeater:

None
Carlos account → A GET request of its "my account" page
None
Wiener account → A POST request that submits the form for email change

Carlos: My account page GET request Wiener: Form submitting POST request

I sent Carlos' GET request to the server to get a new CSRF token. I got:

None
CSRF token in response

Then I copied that CSRF token and pasted it into Wiener's POST request to see if it works.

None

In the header, I changed the CSRF value with Carlos' CSRF and sent the request.

It worked. The email address was changed.

Making the PoC

Finally I made a PoC of this POST request.

None

Added auto-submit script:

<script>document.forms[0].submit();</script>

Took a new CSRF token by refreshing Carlos' "my account" page and pasted it into this exploit.

Simply stored it in the HTML hosting page in the lab and delivered it to the victim.

Fooo! Finally the lab was solved.

The question still in my mind

Here in the lab, I have access to both accounts. I can log into the victim account and have the full header request of the victim account. I can also log into the attacker account from where I took that CSRF token and changed it with victim's CSRF.

But in the real world, how does an attacker do this? They only have their own account.

If anyone has the answer, please share it with me too.

That's it for today

See you in the next story. Till then, keep questioning yourself:

What? How? Why?