This blog will discuss about Double Submit Cookie which is the second prevention mechanism of CSRF attack. If you are not aware of CSRF attack and how it works read my previous blogs regarding it.

In the last blog we discussed about Synchronizer Token Pattern, and I mentioned it holds a drawback when there are more login sessions because the server will store the CSRF tokens against the session IDs which might lead overload in the server. This is where the Double Submit Cookie(DSC) comes in play. In DSC, server doesn’t store the token. This is why DSC is also called as Stateless CSRF Defense.

How it works

The above diagram shows how the client browser logs in using the credentials meanwhile a session is created and the session ID is set as the cookie in the client browser.

Next, the server sends the CSRF Token as set cookie header to set the cookie, User access the feedback page which was sent as a response. The CSRF token is extracted from the cookie header and append the Token as hidden file (either in the head or body). Form is submitted along with the CSRF Token and CSRF Cookie.

Server compares the CSRF cookie and the submitted token through the form. If both the are equal the next action is performed else the error message is sent.

For better understanding of this A simple HTML,JavaScript and PHP project is done.

The UN and Password is hardcoded as anony@gmail.com and gT$0om

1.Login with the credentials

Client uses their credentials to login.The server generates Session ID and set it as cookie also generates CSRF Token and store it in a cookie. The following code shows how the token is generated

The server generates the session ID and Token, The token is generated with the help of openssl_random_pseudo_bytes which use to generate random numbers. These random numbers are encoded in base64_encode so that it will be hard to read even when intercepted. The client is redirected to the feedback page to give their thoughts.

2.Feedback Form sent as response along with Set-cookie Header

The above code is same as the form created in Synchronizer Token Pattern, the token should be sent in a hidden field, but the function created is to get the CSRF Token from the Cookie which was received from server.

Take the cookiename as parameter (cname). Create a variable (name) with the text to search for (cname + “=”). Decode the cookie string, to handle cookies with special characters, e.g. ‘$’ Split document.cookie on semicolons into an array called ca (ca = decodedCookie.split(‘;’)). Loop through the ca array (i = 0; i < ca.length; i++), and read out each value c = ca[i]). If the cookie is found (c.indexOf(name) == 0), return the value of the cookie (c.substring(name.length, c.length), else return “”. If you need further more details on cookies in javascript look in this.

This source code checks both the cookie and the token are same. If both are equal the next necessary action will take place else denies. This is how the DSC helps to prevent CSRF attack.

The most frequently asked question is “Is the web application safe now?”, I would say “It is partially safe”, DSC is an solution for the drawback in Synchronizer Token Pattern (STP) which might overload the server as the Session IDs and the Tokens are stored in the Server Database. Cookies with sensitive server metadata should be tagged as HTTPOnly flag but in DSC the cookies aren’t tagged in that way, next if the subdomains have potential XSS vulnerabilities it might affect the upper domains. We have to make sure that the web application is XSS-resistant if the application is in the sub domain.

In order to learn more about these, check out this presentation.