Cross Site Request Forgery Protection with Double Submit Cookies Patterns

When a user authenticates to a site, the site should generate a (cryptographically strong) pseudo-random value and set it as a cookie on the user’s machine separate from the session ID. The server does not have to save this value in any way, that's why this pattern is also called Stateless CSRF Defense.

The site then requires that every transaction request include this random value as a hidden form value (or other request parameter). A cross origin attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy.

In the case of this mitigation technique the job of the client is very simple, just retrieve the CSRF cookie from the response and add it into a special header to all the requests:

Client workflow

The job of the server is a little more complex, create the CSRF cookie and for each request asking for a protected resource, check that the CSRF cookie and the CSRF header of the request are matching:

Implementation of "Double Submit Cookie" Pattern

Use code in the below link for the implementations.

https://github.com/tharushi-pushpakumara/Cross-site-Request-Forgery-protection-with-Double-Submit-Cookies-Patterns

Index.php file is the initial file. It is a single login page. CSRF token is generate by the following code segment

Once logged in, the user is redirected to an another web page. within that web page the CSRF token is generated.



This one way to be protected from CSRF token. there is an another way called Synchronizer token pattern.

Cross Site Request Forgery with Synchronizer Token Patterns

An anti-CSRF token is created and stored in the user session and in a hidden field on subsequent form submits. At every submit, the server checks the token from the session matches the one submitted from the form.

How to implement

For the ease of you implementation you can download my source code from below link.

https://github.com/tharushi-pushpakumara/Cross-site-Request-Forgery-with-Synchronizer-Token-Patterns

Basically we need 3 php files.

1. control.php
2. index.php
3. logout.php

Index.php

This is the main page and it's php code to validate the credentials.

When the user click on login button it redirects to another web page where the user need to provide some details. I have named it as control.php. Through this php file CSRF token is generated.

This is one way to be protected from CSRF attacks. Double submit cookie is an another way to be protected from this type of attack.

RESTful API

Both authorization server and resource server in a single API were created. There is an endpoint called in order to retrieve the resources for the demonstration purposes.
This is written using node.js. To run this on your computer you have to have node.js installed on your computer.

app.js



Oauth grant type is client_credentials. This has to be mentioned in the request body when you try to get the access token from authorization server. Also this app tuns on port 4000. You can give any port number here. There are two endpoints I have created in this. One to get the access token which is "/oauth/token" and the other one is to get resources which is "/profile". As resources I have hard coded one value which is name ("Tharushi") and this comes as a JSON object.

model.js




Here I have created a sample user. (username = admin, password = admin) and all the functions that handle requests from client are written in this file.
To make all get and post requests to the resource server we use RESTclient Mozilla Firefox Add on. You can use other similar products such as Postman for this.
First of all We have to make a POST request to get the access token from the authorization server.
For that we have to send the authorization key in the header.
Authorization : Bearer XXXXXXXXXXXXXXX
And also we have to mention the content type in the header.

I ll demonstrate with RestClient on Mozilla Firefox with creating all the requests manually and of course how to retrieve resources.
Then we have to mention these 3 parameters in the body.

username=test
password=test
grant_type=client_credentials

The URL should be the endpoint that gives us the access token.
http://localhost:4000/oauth/token



When we send this we get the response which has access token in it. This access token also have an expiration time.
Then we have to make a GET request to retrieve the resources we need.




Now our URL is different because we have to call a different endpoint to get these resources which is "http://localhost:4000/profile".

We do not have to mention anything in the body.
In the request header we should send the access token we got in the previous step.

Authization: Bearer XXXXXXXXXXXXXXX

Make sure that the access token is not expired. Otherwise you will get an error message saying that it has expired.

When you sent this request you get a response that contains the resources we specified in the code.

If you are interest on this field you can go through my code and try it out here.