Double Submit Cookie Pattern
In one of my previous posts, I discussed about CSRF attacks. There, I mentioned that Double Submit Cookie Pattern is another method to protect a web application against CSRF attacks. Now, let’s discuss it in detail.
Introduction
This is defined as sending a random value in both a cookie and as a request parameter, with the server comparing whether both are the same. Here, the server does not have to save this random value in anyway. Hence, this security pattern is also called “Stateless CSRF Defense”.
Prevention
When a user authenticates to a site, it generates a session ID and sets a cookie in the browser. At the same time it generates a 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 sessionID.
The site requires every request to include the above mentioned random value as a hidden form value or another request parameter. Note that, an attacker cannot read data sent from the server or modify cookie values, per the same-origin policy.
Here, the client only has to retrieve the CSRF cookie from the response and add it into a special header for requests.
An Example Scenario
The source code of the web application used here: https://github.com/Himashi-Karunathilake/CSRF-Double-Submit-Cookie-Pattern
This login form submits user credentials using POST method. If authenticated, the server side creates a unique sessionID and the CSRF token . Note that, in this scenario, the server will only save the sessionID and not the CSRF token. The server will respond the CSRF token along with the response body. Then, the generated sessionID and the CSRF token are set as cookies in the browser.
Note that the httponly attribute in the cookie is set as “false” so that JavaScript is able to access the CSRF token cookie to add to the hidden field in the POST request.
After the user is redirected to the Add New Blog Post, an AJAX call (self-call) is executed to obtain the stored CSRF token from the browser cookies and it is added to the hidden field.
A POST request is then included to add a new blog post. This request contains the generated CSRF token and the session cookie. When the user clicks on the “Add Post!” button, the POST request is sent. Then, the server validates the cookie header for sessionID and also the CSRF token from the request body (the hidden field value) against the CSRF token from the header cookie. If valid, the server accepts the request and if invalid, the server ignores the request.
Conclusion
Cookies alone cannot provide security to a web application since they are automatically sent with every request, regardless of whether it was initiated by the original site or a third party site. But, by having the token in the request, an attacker cannot generate valid requests anymore as they cannot get hold of the user’s token. Therefore, this method will work against CSRF attacks.
Continue Reading:
Cross — Site Request Forgery (CSRF): Cross — Site Request Forgery (CSRF) | by Himashi Karunathilake | Medium
Synchronizer Token Pattern (STP): Synchronizer Token Pattern (STP). In my previous post, I explained what… | by Himashi Karunathilake | Medium
This assignment was done as a part of the assignment submission for the 2nd Year — 2nd Semester Web Security (WS) module of Sri Lanka Institute of Information Technology (SLIIT).
Originally published at http://mysnowfrostpersonal.wordpress.com on October 11, 2019.
