Cross-Site Request Forgery (CSRF) - Double Submit Cookies Pattern

Cross-Site Request Forgery (CSRF) 

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. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request. 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.

------------------References - OWASP & Other - Wikipedia--------------------------

How to prevent CSRF?

Two types of methods below,

1. Synchronizer Token Pattern 
2. Double Submit Cookie Pattern

Double Submit Cookie Pattern

Double submit cookie pattern" is one of the solution for CSRF attack.

After authenticating to a web application, here a random value sent in both cookie and a request parameter to verify.

If maintaining the state for CSRF token at server side is problematic, an alternative defense is to use the double submit cookie technique. This technique is easy to implement and is stateless. In this technique, we send a random value in both a cookie and as a request parameter, with the server verifying if the cookie value and request value match. When a user visits (even before authenticating to prevent login CSRF), the site should generate a (crypto-graphically strong) pseudo-random value and set it as a cookie on the user's machine separate from the session identifier. The site then requires that every transaction request include this pseudo-random value as a hidden form value (or other request parameter/header). If both of them match at server side, the server accepts it as legitimate request and if they don't, it would reject the request.

Figure 1 - Diagram

Reference

1. User authenticates. Generates session identifier and set cookie in browser and separate random cookie is generated.
2. Every request includes the random value.
3. CSRF cookie retrieved from response.
4. Added to every request as header.
5. Successful mitigation 

***make sure to clear cache and cookie data or use private browsing mode (incognito - Google Chrome).

Implementation

First one is we have to create a web application and host it on our local host (Educational purpose).

Start it on local host and got as index.php. Take the sample project to implement the method.

Figure 2 - Login

This is a simple, As the login credential Enter,
username - admin
password - pass

Figure 3

Login form submits user details in a POST method. With successful login a unique session ID and token is created. Token stored in server side.

Implementation on simple login form.

 Figure 3.1 - index.php

Figure 3.2 - style.css

Figure 3.3 - style.css

Figure 3.4 - style.css

Next one is login you will be redirected to a simple form with one field to enter.

Figure 4

implementation on 'result.php' page. 

Figure 5 - result.php

Figure 5.1 - result.php

Finally can enter any data to Insert Data field.POST request is also used to add data to form. After submitting, the server validates the token details to find a match.If the token is valid the server will accept the request.Here this shown the case of success.

Figure 6

Then it redirect to the 'home.php' page.

Figure 7

Implementation on 'home.php' pages.

Figure 8 - home.php

Implementation on 'token.php' page.

Figure 9 - token.php

when we log in to the server it server starts a session cookie and a session id then it creates 2 set-cookie to send the data to the browser along with CSRF token value and session id.

After the user logged in, I have implemented an Ajax call to get browser cookies(from docmunet.cookie) and I used a split function to get only CSRF token and append it to the hidden field.

When a user updates a status the post request contains this generated CSRF token and the server validates the cookie header from session-id and also server compares CSRF token from request body(hidden field value) against CSRF token from the header cookie. If these tokens are matched then the server accepts the request.

------------>>Click here to get sample project on git-hub

------------>>Synchronizer Token Pattern - Click Here

Hope you got the understanding on how to prevent CSRF using Double Submit Cookie Pattern.