Double Submit Cookie Pattern
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.
This is how 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.
Sample Web Project to demonstrate Double Submit Cookie Pattern
Initially, the user should log in with the hard coded credentials.
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.
Get Rajitha Perera’s stories in your inbox
Join Medium for free to get updates from this writer.
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.
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.
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.
find the sample web application here.
