What Is Cross-Site Request Forgery?
Web developers needs to be aware of CSRF attacks and how they're created. In this post we take a closer look at what they are, how they're used, and how to prevent them.
Join the DZone community and get the full member experience.Join For Free
Cross-Site Request Forgery (CSRF), XSRF, or Sea surf refers to an attack against authenticated web applications using Cookies wherein an attacker is able to trick a victim into making a request the victim did not intend to make. Therefore, with CSRF an attacker abuses the trust a web application has with a victim’s browser.
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 affecting highly privileged users, such as administrators, could result in a full application compromise.
During a Cross-Site Request Forgery (CSRF) attack, the victim’s browser is tricked into sending 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 in order to keep the user from having to re-authenticate for each request, which would obviously be impractical.
If the victim’s authentication session is stored in a Cookie which 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 requests against the website, without the website being able to distinguish whether the requests are legitimate or not.
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
The above is a CSRF attack using an HTTP GET request. If a victim visits a web page controlled by an 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
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 src="http://attacker.com/csrfAttack" style="width:0;height:0;border:0;border:none;"></iframe>
<body onload="document.getElementById('csrf').submit()"> <form id="csrf" action="http://example.com/changePassword.php" method="POST"> <input name="newPassword" value="attackerPassword" /> </form> </body>
Preventing CSRF Vulnerabilities
There are two approaches by which Cross-Site Request Forgery (CSRF) may be prevented – 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.
The recommended and the most widely used prevention technique for preventing Cross-Site Request Forgery (CSRF) attacks is known as an anti-CSRF token, also sometimes referred to as synchronizer tokens.
When a user submits a form or makes some other authenticated request that requires a Cookie, the anti-CSRF 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 is 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.
The same-site 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 same-site 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 same-site Cookie. This effectively eliminates Cross-Site Request Forgery (CSRF) without the use of synchronizer tokens. Unfortunately, this method of CSRF is only effective in some modern browsers.
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.
Published at DZone with permission of Ian Muscat, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.