How I Discovered a Delete CSRF Vulnerability

10 hours ago 6

BOOK THIS SPACE FOR AD

ARTICLE AD

Let’s call the target “target.com.” I registered an account on target.com and explored all available features and actions within the account endpoint. I started analyzing these requests in Burp Suite to understand how they functioned.

During my analysis, I noticed an email update request:

POST /email/update HTTP/2
Host: target.com
x-csrf-token:xxxxxxtokenxxxxxxx
{
"email":"example@mail.com",
"some_param":"fixed-value"
}

The request included an x-csrf-token header, which is typically used to protect against CSRF attacks. However, I wondered what would happen if this CSRF token wasn't properly validated. To test this, I modified the token and resubmitted the request and I received a valid response. I even sent the request without the token and still received a valid response.

I crafted csrf exploit file something looks like this:

<!DOCTYPE html>
<html>
<head>
<title>CSRF</title>
</head>
<body>
<form id="csrfForm" action="https://target.com/email/update" method="POST">
<input type="hidden" name="email" value="attacker@mail.com">
<input type="hidden" name="some_param" value="fixed-value">
</form>
<script>
document.getElementById('csrfForm').submit();
</script>
</body>
</html>

I opened this file in my browser while logged into another account, and it successfully triggered the email update action for the victim

But there is no vulnerability !! target.com requires a verification code sent to the new email address to complete the update.

I then considered other actions that could be exploited via CSRF, such as updating user data (name, number, preferences, etc.) with injected payloads like XSS. Unfortunately, the WAF blocked these requests.

There is no impactful action except deleting user account !I crafted a CSRF exploit file for the account deletion endpoint, and it worked! The victim’s account was deleted, and an email was sent to the victim confirming the deletion. Before reporting the vulnerability, I tested it on a new account to confirm its existence. To my surprise, it didn’t work this time — I received an error response.

At this point i got disappointed and i didn’t know why it don’t work in the new account. After further investigation, I discovered that The victim’s session cookie needed to contain specific data related to certain actions for the exploit to succeed. (I won’t mention the specific action for confidentiality reasons.) In other words, the CSRF attack would only work if the victim had performed a particular action before browsing the attacker’s malicious link.

This is the flow of a successful exploit:
The user triggers a specific action >> browses the attacker’s malicious link >> their account gets deleted.

This finding got accepted as P3 instead of P2 since its conditioned CSRF.

Read Entire Article