Synchronizer Token Pattern: No more tricks

[Source: https://i.ytimg.com/vi/CvtoRtoDrTA/maxresdefault.jpg]

In my previous post on Cross-Site Request Forgery attacks I have discussed about the attack along with real world examples and prevention mechanisms. In this post I will be elaborating more on Synchronizer Token Pattern’s flow and features with an example.

Let’s meet Synchronizer Token Pattern

Synchronizer Token Pattern in a nutshell

To overcome this issue, another attribute know as synchronizer token will be generated from the server side and added to the form that goes through a POST request by requesting the corresponding CSRF token from the server through an AJAX call. So that now, the server not only checks the session ID corresponding to the username but also checks the CSRF token and only if both attributes are matched correctly the money transferring activity will be take place.

Why can’t the attacker get the synchronizer token?

More over the request will be protected by the same origin policy, and it will not be able to read the token from the response since cross-domain AJAX calls are blocked by default. This is why Synchronizer Token Pattern in considered to be the most secure mechanism for CSRF attacks.

Money Transfer Application Example

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 Synchronizer Token Pattern used in a Money Transfer Application

The flow of the Synchronizer Token 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 token is known as the CSRF token or synchronizer token.
  4. The cookie will be sent to the client along with the “Money transfer” page.
  5. Cookie storage : The cookie will be stored in the browser cookie storage. The cookie is used to store the state changes of the user.
  6. Retrieval of CSRF token : The money transfer page internally execute an Ajax call via a java script, which invokes the endpoint to obtain the CSRF token created for the session. Because to further proceed with any POST requests, the request needs to be sent with the CSRF token along with the session cookie.
  7. The server examines the request that comes along with the session cookie and gets the corresponding CSRF token generated for that particular session ID which is extracted from the cookie.
  8. The CSRF token will be sent to the client.
  9. Binding the CSRF token into a hidden form field : The received CSRF token will be 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 cookie.
  10. Synchronizer Token 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 stored in the server side for the given session ID.
  11. 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 AuthenticationServiveImpl class.

AuthenticationServiceImpl.java

Once the authentication is scuccessfully completed, the corresponding cookie will be generated and stored. 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 home.html page is as follows.

home.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 an AJAX call is made and the retrieved token is embedded in the form. This is shown as follows.

TransferController.java
main.js

Finally if the POST request had the valid CSRF token 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 synchronizer token pattern in this Git Link.

Stay tuned to crack more interesting information on “Double Submit Cookie Pattern” in my next blog post.

Inquisitive