What is Cross-site Request Forgery(CSRF)?
Cross-site Request Forgery(CSRF) is a web application vulnerability that allows attacker to manipulate the user(victim) to perform what the user unintended to perform. Here the attacker uses existing target site functionality which is not securely implemented and manipulate the user to make them feel the site is legitimate to perform the tasks.
What is the impact of Cross-site Request Forgery?
Impact of Cross-site Request Forgery depends on the nature of the action that will be performed by the user(victim). Sometimes the user can get the full control over the user’s account. If the user(victim) has a higher privilege in the application, then the attacker might be able to take full control of the application.
How does CSRF works?
Let us take an application functionality, which lets the user to change the email for their account. Assume that application is not validating the CSRF token and also assume that user is already loged
Usually when the user perform the action, the HTTP request will be like:
POST /email/update HTTP/1.1
Host: target.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 29
Cookie: session=DfghgsgtteuyfgFAHdschgnEuIxhasN
email=chanukya@target.comThis request is enough to change the email of the user. Now attacker will create a web page for the attack.
<html>
<body>
<form action="https://target.com/email/update" method="POST">
<input type="hidden" name="email" value="attacker@target.com" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>The link for the site will be sent to user(victim). Once the user click on the link. The script will be executed directly, which contains the form submission. Since we assumed, the user logged into the target site, the browser will automatically include the session in the request. As the target site is not added anymore validations, the request will be processed normally and the email will be updated. Now the account will be under the control of the attacker as the updated email belongs to attacker.
Common defenses against CSRF
The most common defenses you’ll encounter are as follows:
CSRF tokens — A CSRF token is a unique, secret, and unpredictable value that is generated by the server-side application and shared with the client. When attempting to perform a sensitive action, such as submitting a form, the client must include the correct CSRF token in the request. This makes it very difficult for an attacker to construct a valid request on behalf of the victim.
SameSite cookies — SameSite is a browser security mechanism that determines when a website’s cookies are included in requests originating from other websites. As requests to perform sensitive actions typically require an authenticated session cookie, the appropriate SameSite restrictions may prevent an attacker from triggering these actions cross-site. Since 2021, Chrome enforces Lax SameSite restrictions by default. As this is the proposed standard, we expect other major browsers to adopt this behavior in future.
Referer-based validation — Some applications make use of the HTTP Referer header to attempt to defend against CSRF attacks, normally by verifying that the request originated from the application’s own domain. This is generally less effective than CSRF token validation.
Note: Bypassing the CSRF will be published in another writeup.
