Cross-site Request Forgery, also known as CSRF is an attack whereby an attacker tricks an end user to execute unwanted actions on a web application in which they’re currently authenticated. The impact of the attack depends on the level of permissions that the victim has on the application. Such attacks take advantage of the fact that a website completely trusts a user once it can confirm that the user is indeed who they say they are.

CSRF attacks exploit the trust a Web application has in an authenticated user. (Conversely, cross-site scripting (XSS) attacks exploit the trust a user has in a particular Web application). A CSRF attack exploits a vulnerability in a Web application if it cannot differentiate between a request generated by an individual user and a request generated by a user without their consent.

CSRF is an attack that tricks the victim into submitting a malicious request on behalf of an attacker. It inherits the identity and privileges of the victim to perform an undesired function on the victim’s behalf. For most sites, browser requests automatically include any credentials associated with the site, such as the user’s session token, IP address and so forth. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish between the forged request sent by the victim and a legitimate request sent by the victim.

How Are CSRF Attacks Executed

There are two main parts to executing a Cross-site Request Forgery attack. The first one is tricking the victim into clicking a link or loading a page. This is normally done through social engineering and malicious links. The second part is sending a crafted, legitimate-looking request from the victim’s browser to the website. The request is sent with values chosen by the attacker including any cookies that the victim has associated with that website. This way, the website knows that this victim can perform certain actions on the website. Any request sent with these HTTP credentials or cookies will be considered legitimate, even though the victim would be sending the request on the attacker’s command.

When a request is made to a website, the victim’s browser checks if it has any cookies that are associated with the origin of that website and that need to be sent with the HTTP request. If so, these cookies are included in all requests sent to this website. The cookie value typically contains authentication data and such cookies represent the user’s session. This is done to provide the user with a seamless experience, so they are not required to authenticate again for every page that they visit. If the website approves of the session cookie and considers the user session still valid, an attacker may use CSRF to send requests as if the victim was sending them. The website is unable to distinguish between requests being sent by the attacker and those sent by the victim since requests are always being sent from the victim’s browser with their own cookie. A CSRF attack simply takes advantage of the fact that the browser sends the cookie to the website automatically with each request.

Let’s say that the online banking application is built using the GET method to submit a transfer request. As such, Jimm’s request to transfer $500 to Alex (with account number 252525) might look like this:

GET https://demobank.com/onlinebanking/transfer?amount=500&accountNumber=252525 HTTP/1.1

Aligning with the first requirement to successfully launch a CSRF attack, an attacker must craft a malicious URL to transfer $5,000 to the account 262626:

https://demobank.com/onlinebanking/transfer?amount=5000&accountNumber=262626

Using various social engineering attack methods, an attacker can trick Jimm into loading the malicious URL. This can be achieved in various ways. For instance, including malicious HTML image elements onto forms, placing a malicious URL on pages that are often accessed by users while logged into the application, or by sending a malicious URL through email.

The following is an example of a disguised URL:

<img src = “https://demobank.com/onlinebanking/transfer?amount=5000&accountNumber=262626” width=“0” height= “0”>

Consider the scenario that includes an image tag in an attacker-crafted email to Jimm. Upon receiving it, Jimm’s browser application opens this URL automatically—without human intervention. As a result, without Jimm’s permission, a malicious request is sent to the online banking application. If Jimm has an active session with demobank.com, the application would treat this as an authorized amount transfer request coming from Jimm. It would then transfer the amount to the account specified by an attacker.

There are some limitations. To carry out a successful CSRF attack, consider the following:

1. The success of a CSRF attack depends on a user’s session with a vulnerable application.
2. The attack will only be successful if the user is in an active session with the vulnerable application.
   An attacker must find a valid URL to maliciously craft. The URL needs to have a state-changing effect on the target application.
3. An attacker also needs to find the right values for the URL parameters. Otherwise, the target application might reject the malicious request.

How to Prevent Cross-Site Request Forgery Attacks

An attacker can launch a CSRF attack when he knows which parameters and value combination are being used in a form. Therefore, by adding an additional parameter with a value that is unknown to the attacker and can be validated by the server, you can prevent CSRF attacks. Below is a list of some of the methods you can use to block cross-site request forgery attacks.

Implement an Anti-CSRF Token

An anti-CSRF token is a type of server-side CSRF protection. It is a random string that is only known to the user’s browser and the web application. The anti-CSRF token is usually stored inside a session variable. On a page, it is typically in a hidden field that is sent with the request.

If the values of the session variable and the hidden form field match, the web application accepts the request. If they do not match, the request is dropped. In this case, the attacker does not know the exact value of the hidden form field that is needed for the request to be accepted, so he cannot launch a CSRF attack. In fact, due to same origin policy, the attacker can’t even read the response that contains the token.

Use the SameSite Flag in Cookies

The SameSite flag in cookies is a relatively new method of preventing CSRF attacks and improving web application security. In the above scenario, we saw that https://attacker.com/ could send a POST request to https://example.com/ together with a session cookie. This session cookie is unique for every user, so the web application uses it to distinguish users and to determine if they are logged in.

If the session cookie is marked as a SameSite cookie, it is only sent along with requests that originate from the same domain. Therefore, when https://example.com/index.php wants to make a POST request to https://example.com/post_comment.php, it is allowed. However, https://attacker.com/ can’t send POST requests to https://example.com/post_comment.php, since the session cookie originates from a different domain, so it is not sent along with the request.

To learn more on web application security, apply for our Web Application Security course here.