Double Submit Cookies Pattern

Malindu Attygala ||IT17174404

Securing Your PHP Web Application Using Double Submit Cookies Pattern

Double Submit Cookies against Synchronizer Tokens

Both of these methods use a CSRF token and Session ID to validate a session.

In Synchronizer token pattern, both are saved in server-side storage, But in Double Submit Cookies pattern, they are stored in the browser as browser cookies. This is the main difference between these two approaches.

Double Submit Cookies Pattern — how does it work?

When a user authenticates to a site, the site should generate a session identifier and set a cookie in the browser. At the same time, it generates the cryptographically strong random value or the CSRF token for the session 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 sometimes also called Stateless CSRF Defense.

The site then requires that every request include this random value as a hidden form value (or another 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.

Let’s look a sample project,

This application is developed using PHP ( Github link — click here)

First, you need to login to the application by entering username and password. For the demo, I have hardcoded the credentials(username: admin, password: password)

Login Screen

Login html post req

This login form submits user credentials using a POST method. if the user is authenticated successfully, server-side will creates a unique Session-Id and the CSRF token but the server only stores the Session-Id. Importantly server doesn’t store CSRF token in this scenario.

Then the server will response the corresponding CSRF token along with the response body. After that generated session id & server respond CSRF token set as cookies in the browser.

In here we must set the httponly flag “false” because js should able to access the csrf token cookie to add to the hidden field in the post request.

Cookie setup code segment

Control.php page which compares the two received token values

Stored CSRF token

Then after user will redirect to user status update page. In this page, I have implemented an AJAX call(self-call) to get the stored CSRF token from the browser cookies.

AJAx call

Then the corresponding CSRF token added to the hidden field.

AJAX call

How we can say the method is safe?

Cookies are sent automatically with every request, regardless of whether the request was initiated by the original site or by a third party site. That’s why a cookie alone does not suffice as every request will contain it.

But by having the token also in the request itself, an attacking site cannot generate valid requests any more as they can’t get hold on the user’s token.

Conclusion

The Double Submit Cookie Pattern techniques described in this story are viable and worth a thought for any application that contains useful data.