Double Submit Cookie Pattern: Smart people always double check their work

[Source - http://www.abbottcartoons.com/wp-content/uploads/BA0329-hole-shouldnt-be-there-copy-1-400x499.jpg]

Double Submit Cookie Pattern is another mechanism used against CSRF attack just like Synchronizer Token Pattern. Though both the mechanisms are similar in flow one major difference in Double Submit Cookie Pattern is that the CSRF token is not stored in the server side. Rather, while sending the session cookie, the server generates another cookie for CSRF token and send it to the client. So that when a request is sent to the server, the server will compare the CSRF token in the request body (CSRF token in the hidden field) and the token in the cookie to see whether both of them are matching or not. If both the tokens match then the intended state changing operation will get executed successfully. Since both the CSRF tokens are from the client side this is known as Double Submit Cookie Pattern.

The following Money Transfer Application was built on top of spring boot ( a framework for bootstrapping and developing new Spring applications) framework in order to illustrate the Double Submit Cookie Pattern flow.

Let’s take a look at the money transfer application’s overall high level architecture in the below Fig 1.

Fig 1 - High-level Architecture diagram of Double Submit Cookie Pattern used in a Money Transfer Application

The flow of the Double Submit Cookie Pattern shown in Fig 1 as follows,

  1. Login : The user provides the username and password in the login form and sends it to the server though a POST request (assume that the user is login to the system for the first time — new session).
  2. User Authentication : Once the server receives the request it authenticates the user and upon the valid credentials the server will generates the sessionID. The sessionID will be stored against the username and put into a cookie.
  3. CSRF Token Generation : Next a token will be generated and stored against the sessionID of the user. This also will be a cookie.
  4. The cookies will be sent to the client along with the “Money transfer” page.
  5. Cookie storage : The cookies will be stored in the browser cookie storage. The cookies are used to store the state changes.
  6. Binding the CSRF token into a hidden form field : From the token cookie the CSRF token will be extracted and then embedded as a hidden field in the form. Once the relevant input fields have been filled the form will be sent through a POST request to the server along with the corresponding cookies. Token cookie is also included in this.
  7. Double Submit Cookie Pattern validation: The server validates the request by comparing whether the token that comes in the request body is same as the token that is in the token cookie.
  8. Message Alert : If the received CSRF token is valid, success message will be shown to the user. If not error message will be shown.
Fig 2 - Login Page

The following login.html which uses Thymleaf shows the implementation of the login page.

login.html

The login credentials are submitted to the server using a POST request. Once the username and password are registered in the application, the app hashes the password using SHA256. So during the login process when the user enters the username and password, the entered password will be hashed using the same hash algorithm and compared against the stored password. This basic user validation is done in the AuthenticationService class. Also all the necessary validations against session, user authentication and CSRF token are placed inside AuthenticationService class.

AuthenticationService.java

Once the authentication is successfully completed, the corresponding session and token cookies will be generated and sent to the client. The overall login flow can be viewed in the LoginController.

LoginController.java

Once the login is completed successfully the money transfer page will be displayed which includes the state changing operation, transferring the money from one account to another.

Fig 3 - Money transfer page

Corresponding transfer.html page is as follows.

transfer.html

Once the form is ready to be sent through a POST request, the CSRF token needs to be embedded within the form in a hidden field. For this purpose a java script is executed to get the token cookie and extract the token from that cookie. Then the retrieved token is embedded in the form. This is shown as follows.

main.js
TransferController.java

In the server side the request validation will take place. If the POST request had the valid CSRF token that aligns with the token in the token cookie then the server will returns a success message. The success message will be shown as follows.

Fig 4 - Transaction with success message (after the state changing operation)

I hope that this article was useful reading and keep on working to provide secure software. You can view the full implementation of double submit cookie pattern in this Git Link.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store