Cross-site Request Forgery (CSRF/XSRF), also sometimes called sea surf or session riding, refers to an attack against authenticated web applications using cookies. The attacker is able to trick the victim into making a request that the victim did not intend to make. Therefore, the attacker abuses the trust that a web application has for the victim’s browser. While Cross-site Request Forgery (CSRF) attacks do not provide an attacker with the response returned from the server, a clever attacker could cause a fair amount of damage, especially when paired with well-crafted social engineering attack on administrative users.
Cross-site Request Forgery (CSRF) is a type of confused deputy attack, which leverages the authentication and authorization of the victim when a forged request is being sent to the web server. Therefore, a CSRF vulnerability that affects highly privileged users, such as administrators, could result in a full application compromise. During a successful CSRF attack, the victim’s web browser is tricked by a malicious website into unwanted action – it sends HTTP requests to the web application as intended by the attacker. Normally, such a request would involve submitting forms present on the web application to alter some data.
Upon sending an HTTP request (legitimate or otherwise), the victim’s browser will include the cookie header. Cookies are typically used to store a user’s session identifier so that the user does not have to enter their login credentials for each request, which would obviously be impractical. If the victim’s authentication session is stored in a session cookie that is still valid (a browser window/tab does not necessarily need to be open), and if the application is vulnerable to Cross-site Request Forgery (CSRF), then the attacker can leverage CSRF to launch any desired malicious requests against the website and the server-side code is unable to distinguish whether these are legitimate requests.
CSRF attacks can, for example, be used to compromise online banking by forcing the victim to make an operation involving their bank account. CSRF can also facilitate Cross-site Scripting (XSS). Therefore, CSRF should be treated as a serious web application security issue, even though it is not currently included in the OWASP Top 10.
Cross-site Request Forgery in GET Requests
The following is a simple example of how Cross-site Request Forgery (CSRF) can be abused in GET requests through the use of the <img> tag.
<img src="http://example.com/changePassword.php/?newPassword=attackerPassword">
The above is a CSRF attack using an HTTP GET request. If the victim visits a web page controlled by the attacker with the following payload, the browser will send a request containing the cookie to the attacker-crafted URL.
Cross-site Request Forgery in POST Requests
GET requests, however, are not the only HTTP method an attacker can abuse. POST requests are equally susceptible to Cross-site Request Forgery (CSRF), however, an attacker will need to make use of a little bit of JavaScript to submit the POST request.
The following is a simple example of how CSRF can be abused using POST requests through the use of an <iframe> tag. This code would be loaded in an iframe which is made invisible to the victim.
iframe definition
<iframe src="http://attacker.com/csrfAttack" style="width:0;height:0;border:0;border:none;"></iframe>
iframe HTML contents
<body onload="document.getElementById('csrf').submit()">
<form id="csrf" action="http://example.com/changePassword.php" method="POST">
<input name="newPassword" value="attackerPassword" />
</form>
</body>
CSRF Protection
There are two primary approaches to prevent Cross-site Request Forgery (CSRF) – synchronizing the cookie with an anti-CSRF token that has already been provided to the browser or preventing the browser from sending cookies to the web application in the first place.
Anti-CSRF Tokens
The recommended and the most widely used prevention technique for Cross-site Request Forgery (CSRF) attacks is known as an anti-CSRF token, sometimes referred to as a synchronizer token or just simply a CSRF token. When a user submits a form or makes some other authenticated request that requires a cookie, a random token should be included in the request. The web application will then verify the existence and correctness of this token before processing the request. If the token is missing or incorrect, the request can be rejected.
It’s highly recommended that you use an existing, well tested and reliable anti-CSRF library. Depending on your language and framework of choice, there are several high-quality open source libraries that are ready-to-use. The characteristics of a well designed anti-CSRF system involve the following attributes:
- The anti-CSRF token should be unique for each user session
- The session should automatically expire after a suitable amount of time
- The anti-CSRF token should be a cryptographically random value of significant length
- The anti-CSRF token should be cryptographically secure, that is, generated by a strong pseudo-random number generator (PRNG) algorithm
- The anti-CSRF token can be added as a hidden field for forms or within URLs (only necessary if GET requests cause state changes, that is, GET requests are not idempotent)
- The server should reject the requested action if the anti-CSRF token fails validation
SameSite Cookies
The SameSite cookie attribute is a new attribute that can be set on cookies to instruct the browser to disable third-party usage for specific cookies. The SameSite attribute is set by the server when setting the cookie and requests the browser to only send the cookie in a first-party context. Therefore, the request has to originate from the same origin – requests made by third-party sites will not include the SameSite cookie. This effectively eliminates Cross-site Request Forgery attacks without the use of synchronizer tokens. Unfortunately, this method of CSRF protection is not yet effective in all web browsers but more and more browsers start to use it.
How to Prevent Cross-site Request Forgery (CSRF) – Generic Tips
Cross-site Request Forgery (CSRF) vulnerabilities are dangerous partly because preventing them is not that easy. There are multiple methods that you can use to avoid them but not all are effective in all scenarios. In addition to two methods that are considered the most effective, there are certain general strategic principles that you should follow to keep your web application safe.
 |
Step 1: Train and maintain awarenessTo keep your web application safe, everyone involved in building the web application must be aware of the risks associated with CSRF vulnerabilities. You should provide suitable security training to all your developers, QA staff, DevOps, and SysAdmins. You can start by referring them to this page. |
 |
Step 2: Assess the riskCSRF vulnerabilities do not apply to public content. They are only dangerous when authentication is required. Therefore, you can ignore this risk if you only have public content on your website. However, if you have a web application with user accounts, be extra vigilant. Treat CSRF as a major risk if you have an e-commerce application. |
 |
Step 3: Use anti-CSRF tokensAnti-CSRF tokens are considered the most effective method of protecting against CSRF. Use a tested implementation such as CSRFGuard for Java or CSRFProtector for PHP to implement your anti-CSRF tokens. Develop your own mechanism only if there is no existing one for your environment. |
 |
Step 4: Use SameSite cookiesSet the SameSite attribute of your cookies to Strict. If this would break your web application functionality, set the SameSite attribute to Lax but never to None. Not all browsers support SameSite cookies yet, but most do. Use this attribute as additional protection along with anti-CSRF tokens. |
 |
Step 5: Scan regularly (with Acunetix)CSRF vulnerabilities may be introduced by your developers or through external libraries/modules/software. You should regularly scan your web applications using a web vulnerability scanner with a CSRF scanner module, such as Acunetix. If you use Jenkins, you should install the Acunetix plugin to automatically scan every build. |
Frequently asked questions
Cross-site request forgery (CSRF) is a type of vulnerability. It happens when a web server receives a malicious request from a trusted browser. For example, a malicious hacker can send the victim a link that transfers money from the victim’s online bank account to the attacker’s account. If the victim is logged in to the site, the vulnerable application executes the action when the victim clicks the link.
As summarized in the latest Acunetix Web Application Vulnerability Report, cross-site request forgery is becoming less widespread. However, such vulnerabilities still exist in as much as thirty percent of websites and web applications.
Read the full Acunetix Web Application Vulnerability Report.
You can detect cross-site request forgery using manual penetration testing (slow and expensive) or by using an automated web vulnerability scanner. Acunetix detects all cross-site request forgery vulnerabilities, both in known tools like WordPress plugins as well as your own applications.
There are several methods to avoid cross-site request forgery. The most popular one is anti-CSRF tokens. Such tokens are added to all forms that include state-changing operations. When the user submits such a form, the web application checks if the token is there and if it is correct. You can also use SameSite cookies, but this will not work with all browsers yet.
See how Chrome implements protection against cross-site request forgery.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
