Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.

CSRF Protection –

Check if your framework has built-in CSRF protection and use it

If framework does not have built-in CSRF protection, add CSRF tokens to all state changing requests (requests that cause actions on the site) and validate them on the backend

For stateful software use the synchronizer token pattern

For stateless software use double submit cookies

Implement at least one mitigation from Defense in Depth Mitigations section

Consider implementing user interaction based protection for highly sensitive operations

Consider the use of custom request headers

Consider verifying the origin with standard headers

Remember that any Cross-Site Scripting (XSS) can be used to defeat all CSRF mitigation techniques!

Do not use GET requests for state changing operations.

If for any reason you do it, protect those resources against CSRF.

How does the attack work?

There are numerous ways in which an end user can be tricked into loading information from or submitting information to a web application. In order to execute an attack, we must first understand how to generate a valid malicious request for our victim to execute. Let us consider the following example: Alice wishes to transfer $100 to Bob using the web application that is vulnerable to CSRF. Maria, an attacker, wants to trick Alice into sending the money to Maria instead. The attack will comprise the following steps:

1. Building an exploit URL or script

2.Tricking Alice into executing the action with Social Engineering

GET scenario

If the application was designed to primarily use GET requests to transfer parameters and execute actions, the money transfer operation might be reduced to a request like:


Maria now decides to exploit this web application vulnerability using Alice as the victim. Maria first constructs the following exploit URL which will transfer $100,000 from Alice’s account to Maria’s account. Maria takes the original command URL and replaces the beneficiary name with herself, raising the transfer amount significantly at the same time:

The social engineering aspect of the attack tricks Alice into loading this URL when Alice is logged into the bank application. This is usually done with one of the following techniques:

The exploit URL can be disguised as an ordinary link, encouraging the victim to click it:

<a href="">View my Pictures!</a>

Or as a 0x0 fake image:

<img src="" width="0" height="0" border="0">

If this image tag were included in the email, Alice wouldn’t see anything. However, the browser will still submit the request to without any visual indication that the transfer has taken place.

A real life example of CSRF attack on an application using GET was a uTorrent exploit from 2008 that was used on a mass scale to download malware.

POST scenario

The only difference between GET and POST attacks is how the attack is being executed by the victim. Let’s assume the bank now uses POST and the vulnerable request looks like this:



Such a request cannot be delivered using standard A or IMG tags, but can be delivered using a FORM tags:

<form action="" method="POST">

<input type="hidden" name="acct" value="MARIA"/>
<input type="hidden" name="amount" value="100000"/>
<input type="submit" value="View my pictures"/>


This form will require the user to click on the submit button, but this can be also executed automatically using JavaScript:

<body onload="document.forms[0].submit()">


CSRF Impact :-

The impact of a successful CSRF attack is limited to the capabilities exposed by the vulnerable application and privileges of the user. For example, this attack could result in a transfer of funds, changing a password, or making a purchase with the user’s credentials. In effect, CSRF attacks are used by an attacker to make a target system perform a function via the victim’s browser, without the victim’s knowledge, at least until the unauthorized transaction has been committed.