Double Submit Cookie Pattern

Previously, I have discussed the Synchronizer Tokens Pattern as one of the solutions for the Cross Site Request Forgery attack on Web Applications.

This blog post will discuss Double Submit Cookie Pattern to prevent from CSRF attack.

What does it mean?

Double submitting cookies is defined as sending a random value in both a cookie and as a request parameter, with the server verifying if the cookie value and request value are equal.

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 & JS( 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: pass)

                                                   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

                                                                 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.

                                                 Hidden field with value

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.

                                                Accepted 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.

Conclusion

 

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