Cross-Site Request Forgery (CSRF) is an attack whereby a malicious website will send a request to a web application that a user is already authenticated against from a different website. This way an attacker can access functionality in a target web application via the victim’s already authenticated browser. Targets include web applications like social media, in-browser email clients, online banking and web interfaces for network devices.

Key Concepts of CSRF

Malicious requests are sent from a site that a user visits to another site that the attacker believes the victim is validated against.

The malicious requests are routed to the target site via the victim’s browser, which is authenticated against the target site.

The vulnerability lies in the affected web application, not the victim’s browser or the site hosting the CSRF.

How a CSRF attack happens?

In a Cross-Site Request Forgery attack, the attacker is exploiting how the target web application manages authentication. For CSRF to be exploited, the victim must be authenticated against (logged into) the target site. For instance, let’s say financecompany.com has online banking that is vulnerable to CSRF. If I visit a page containing a CSRF attack on financecompany.com but am not currently logged in, nothing happens. If I am logged in, however, the requests in the attack will be executed as if they were actions that I had intended to take.

There are two ways to mitigate the CSRF vulnerabilities.

1.Double submit cookie method

2.Synchronizer token pattern method

Double Submit Cookie Pattern

When a user logs into the site, a session is created and the session ID is set as a cookie in the browser. At the same time, another cookie is set for the CSRF token.

Next, when the user submits a secure form, this token is extracted from the cookie and is set as a hidden input field in the HTML. This cookie cannot be set as HttpOnly as the client side script requires to access this because in this scenario, the token endpoint does not exist and the server has no record of the generated token for this session.

The server will validate the token sent as a form parameter against the cookie value and authorize the action to be completed. A cross-origin attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy.

Implemented using PHP;

Along with the session cookie the CSRF cookie is also generated and saved in the web browser.

If you want to send it in a http request is it not secured so you have to set the cookie as follows.

setcookie(‘csrf_token’, $token, time() + 3600, ‘/’, ‘localhost’,false);

But here as it is https it is stated as true you have to send in the request.

From the CSRF cookie get the generated CSRF token. And also the input type of the token should be in hidden form.

Then you have to validate the CSRF token before proceeding.

And if the token is validated then the Double Submit Cookie pattern is successfully implemented.

The main advantage in this method is as tokens are not saved in the server side as storing CSRF Token in the server may cause a memory overflow with the growth of users. This is what the advantage of using Double Submit Cookie Pattern over Synchronizer Token Pattern.

And the main disadvantage is if the website is vulnerable for XSS attacks the attacker can steal the cookie .

Synchronizer Token Pattern Method

This is the process cannot be done by an attacker because when the attacker try to request token from token endpoint (token URL) it return fail, because ajax code cannot be written in cross site domains. So the attacker cant acquire the token and at the end the request will fail.

Implementation using PHP

The server should reply with the token value when we execute the ajax code shown below.

ajax code used to generate token

The input type of the token should be hidden .

Token Validation Implementation PHP;

Given below is the link to the complete implementation

https://github.com/lavasquabble/CSRF-Protection