Double Submit Cookie Pattern

Previously, I have written article to know about CSRF and Synchronizer Token Pattern. link

As discussed previously Synchronizer Token pattern, the server will store the CSRF tokens against the session IDs. This introduces a concern as sessions cost memory and may result in imbalances in terms of load distribution across web servers. With a significant amount of users consuming the system at a given time, the memory used will also grow exponentially. This is when Double Submit Cookie pattern comes to play. In Double Submit Cookie Pattern, the server will not store the tokens, hence called Stateless CSRF Defense.

Double submit is a variation of the token scheme where the client is required to submit the token both as a request parameter and as a cookie. A malicious page on another domain cannot read the CSRF cookie before its request and thus cannot include it as a request parameter.

This pattern is called as stateless CSRF defense, because token or session_id do not save in server side.

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.

Example Implementation

Step 1 – index.php

This is page first load in web page. Login form included.

Step 2 - validateClass.php

Here validate the form inputs  and check whether username and password correct or not. If credentials are wrong return error to index page.

You can see validate Class use to create two cookies, one to save session id and other one to save CSRF token. If the username and password are correctly validated, a session is started with the session_start() function. Session variables are set with the PHP global variable: $_SESSION. Same time redirected to home.page.

Step 3 - home.php

Javascript function is written to retrieve the CSRF value from the CSRF cookie set on the browser. Then DOM will be modified with the value that is retrieved from the CSRF cookie.

here is code where form to send state change post request.

Then the corresponding CSRF token added to the hidden field.

After form submission, it will redirect to tokenValidatorClass.php.

STEP 4 - tokenValidatorClass.php

In this validation page first check whether form values and CSRF token exists or not. Then token that sent along with form data by home page and token value which earlier saved in Cookies are compare to check equality. If it fails, page redirect to error page and if success, redirect to home page with success message.

I have implemented a POST request to update some user status. The post request contains this generated CSRF token and the session cookie.

When the user clicks “updatepost” btn the Post request send. Then the server validates the cookie header for session id and also server compares CSRF token from request body(hidden field value) against CSRF token from the header cookie. If these tokens matched then server accepts the request.

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.

Hope you guys understand clearly how Double Submit Cookie Pattern added to your web application to secure CSRF attacks. Full implementation of this sample app can be found at https://github.com/NaveenWimalaveera/CSRF-Double-Submit-Cookie_Pattern

Conclusion

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