Cross-site Request Forgery (CSRF) is one of the vulnerabilities on OWASP’s Top 10 list. Its an attack used to make requests on behalf on the user. OWASP is a non-profit organization with the goal of improving the security of software and the internet. We cover their list of the ten most common vulnerabilities one by one in our OWASP Top 10 blog series.
Description
Cross-Site Request Forgery, or CSRF attack, is when an attacker is able to make requests on behalf of a user. Typically the attacker takes advantage of the fact that the user is already authenticated. In other versions of this attack (e.g. Login CSRF) that is not needed.
As the attacker cannot read the response, it is not of any use to force the victim to retrieve data. CSRF only targets state-changing requests such as changing credentials, transferring funds, modifying settings, etc.
Prevalence
In 2010, OWASP ranked this vulnerability as 5th on their list of the most important vulnerabilities. In 2013, it dropped to the 8th place and its prevalence went from widespread to common thanks to improvements of some frameworks to automatically protecting against this and overall awareness of this attack. However we still see this vulnerability commonly present, and this report from CVE Details shows that applications are still at risk to cross-site request forgery today.
CSRF has begun to appear is in API calls. It has become more popular to execute sensitive requests over different APIs instead of regular requests, and developers may forget a token is needed there as well. A web vulnerability scanner can be added to developer workflow to assist with checking the code, including CSRF and other OWASP security risks, before deployment.
Log in to check your security status for CSRF vulnerability.
Potential impact of Cross-site Request Forgery
Assuming the target is a normal user, a successful attack could lead to any state-changing request being executed on the user’s behalf. The same applies if an admin is the target, but the request would then be executed with admin privileges. In the latter case it could potentially lead to a full system takeover.
Exploitability
The user can be compromised when clicking a link or visiting a page with the link embedded. The latter for example could be an img tag. That can be implanted by hacking a site the attacker knows the user will visit, MITMing the user, send the user an email to trick them to click the link.
It is sometimes possible to store the CSRF attack vector on the vulnerable site, which would make this more likely to be abused as it would be easier to spread. An example would be a forum where an attacker could include a picture and then choose the crafted CSRF link as source.
Well-known events
Less than three years ago security researchers were able to identify that 300.000 home routers had been compromised. The DNS settings had been changed, giving the attacker control over every request sent from devices using the router. The attack method used varied, and for some of the routers they used CSRF vulnerabilities. By simply visiting a webpage with the CSRF payload, all traffic from thereon could be controlled by the attackers.
How to discover Cross-site Request Forgery
- Look for any link, form or API call that lacks a CSRF token or other protection.
- There are also some common misconceptions about CSRF protection, look into that and see if the developer seems to have fallen for any of them. See the Remediation section for examples of what is not enough.
Example of CSRF vulnerable application
Let’s assume there is a bank interface that looks something like this:
The request for sending 10 USD to account #1234 would look like this:
https://example.com/send.php?amount=10&account=1234
As there is no token or any other protection mechanism implemented, an attacker can send this link to a logged-in user. When the user clicks the link, 10 USD will be transferred to the account #1234.
An attacker could buy an advertisement on a popular website in the same as country the bank, and include the snippet of code below to carry out CSRF attacks. The potential damage should be obvious.
Remediation
- For every request that is considered important or sensitive, an unpredictable token should be included. These must at a minimum be unique per user session, but could be randomly generated for each request.
- Another solution that is often used with the most sensitive forms is re-authentication, meaning that the user needs to enter the password twice. A common application of this are change-password fields, but the same method can be implemented with other forms as well with the same result. However, the user experience could be aggravated by having to enter the password all the time, so it should be used sparingly.
- Today, many frameworks have built-in protection mechanism against CSRF attacks. Check to see if it’s been enabled for your applications.
- Read more details on the OWASP CSRF Cheat Sheet.
Common misconceptions of CSRF protection
A misconception we often debunk is whether CAPTCHA is sufficient CSRF protection. Long story short, it’s not! You can read the details of why CAPTCHA and reCAPTCHA may not prevent cross-site request forgery here.
Another common misconception is that it is sufficient to only accept POST requests as the attacker then cannot create a malicious link. This is false! With just a few lines of JavaScript the attacker would be able to bypass this.
Remember that IP addresses, session cookies, local storage, etc., are always included in requests, even the forged ones, so only checking such information does not protect against CSRF. An XSS vulnerability would bypass most of the CSRF protections, with re-authentication being the only exception.
How Detectify can help
We provide a quick and easy way to check whether your site passes or fails OWASP Top 10 tests. Detectify is a web security scanner that performs fully automated tests to identify security issues on your website. It tests your website for over 1000 vulnerabilities, including cross-site request forgery and the 2017 OWASP Top 10, and can be used on both staging and production environments. Sign up for a free trial to find out if you are vulnerable.
Looking to discuss a solution or implementation? Contact our support at [email protected]!