How I Found a CSRF Vulnerability Leading to Account Takeover ($2,000 Bounty)

On July 14, 2021, while testing the security of a web application, one of my private bug bounty programs on hackerone, I discovered a critical Cross-Site Request Forgery (CSRF) vulnerability in the password reset functionality. This vulnerability allowed an attacker to take over any user’s account by forcing them to reset their password without their knowledge. After responsible disclosure, the vulnerability was triaged on July 19, 2021, rated with a high severity score (8.8), and rewarded with a $2,000 bounty.

Cross-Site Request Forgery (CSRF) is a type of malicious exploit where unauthorized commands are submitted from a user that the web application trusts. In simple terms, the attack tricks victims into submitting requests they did not intend to make, potentially leading to data theft, account takeover, or other harmful actions. CSRF is also known as XSRF, session riding, or one-click attacks.

While examining the authentication flow, I noticed that the password reset functionality lacked proper CSRF protection. Here’s how I discovered and confirmed the vulnerability:

I logged into my first test account on the authentication pageClicked on “reset password” and entered a new passwordCaptured this request in Burp Suite before clicking “proceed”Used Burp’s engagement tools to generate a CSRF PoC for this requestSaved the PoC as csrf.htmlLogged into a second test account in another browserOpened the csrf.html file in the browser where I was logged in as the second userObserved that I was able to reset the password for the second account without any additional verification

This approach follows the recommended methodology for identifying CSRF vulnerabilities, which focuses on actions that should contain proper protection mechanisms

The vulnerability existed in the password reset endpoint, which accepted POST requests without validating the origin of the request or implementing CSRF tokens. According to OWASP, CSRF tokens should be generated on the server-side and be unique for each request to prevent such attacks.

The vulnerable endpoint accepted POST requests containing parameters for the new password without any CSRF protection mechanism in place. When a user who was authenticated to the application visited a page containing the malicious CSRF code, the browser would automatically include the user’s cookies in the request, allowing the attacker to reset the victim’s password without their knowledge.

To demonstrate the severity of this vulnerability:

I logged into my first account with the original passwordThen logged into a second account in another browserExecuted the CSRF PoC HTML file while logged in as the second userThe password for my second account was successfully changed to the value specified in the CSRF PoCI confirmed this by logging in with the new password

This proof of concept validated that the vulnerability could be exploited without any user interaction beyond visiting the malicious page while being authenticated to the vulnerable application.

The impact of this vulnerability was severe:

An attacker could take over any user’s account by tricking them into clicking a malicious link or visiting a malicious webpage while authenticatedOnce the password was reset, the attacker would have full access to the victim’s accountThis could lead to data theft, privilege escalation, or further attacks within the applicationNo user interaction was required beyond visiting the attacker’s page while authenticated to the vulnerable site

The severity of this issue was particularly high because it affected a critical authentication function and could lead to complete account compromise with minimal user interaction.

July 14, 2021: Vulnerability discovered and reportedJuly 15, 2021: Initial response from security team requesting more informationJuly 16, 2021: Provided additional details and video PoCJuly 19, 2021: Vulnerability triaged with high severity (8.8)August 5, 2021: Vulnerability resolved and $2,000 bounty awarded

This timeline reflects the recommended approach for responsible vulnerability disclosure, providing clear documentation and proof of concept while allowing the organization time to implement a fix.

To prevent CSRF vulnerabilities like this, I recommended implementing the following security controls:

Add CSRF tokens to all state-changing operations, especially password resetsUse SameSite cookie attribute (set to ‘Lax’ or ‘Strict’) to prevent cross-origin requestsImplement proper validation of Origin and Referer headersRequire additional verification (like current password) for sensitive operationsConsider implementing the double-submit cookie pattern for enhanced protection

These recommendations align with OWASP’s CSRF Prevention Cheat Sheet, which suggests token-based CSRF defense as the primary protection mechanism.

This finding demonstrates how even simple security measures, when missing, can lead to critical vulnerabilities. CSRF protection is a fundamental security control that should be implemented for all sensitive operations, especially those related to authentication and account management.