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

Creating web applications might be an easy job these days with excellent frameworks and stacks but securing the program and giving a stress free user experience is what matters a lot in recent times. CSRF is a very common attack encountered by the end users as stated in the OWASP Top 10. One such mechanism in preventing the users from CSRF attacks is “Synchronizer Token Pattern”.

Synchronizer Token Pattern in a nutshell

Let’s take a money transferring activity that takes place in a banking website. The user will send the credentials(username and password) in the login page through a POST request. The request will be received by the server and validates the credentials against the values stored in the server side. Once the user is authenticated the server will generate the session cookie and store it against the username and send it in the response header. This cookie will be stored in the client side and whenever a request is made to the server the corresponding cookie will also be sent to the server along with the request. By making use of the authenticated user’s privilege the attacker simply sends a malicious script through any social engineering techniques and make the user click on it and act according to the attacker’s wish.

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?

If an attacker is smart enough to make the end-user act according to the attacker’s wish by sending the malicious request with the corresponding cookie from end-user’s side, then why can’t he make the corresponding CSRF token be sent in the same request? Simply because if the attacker’s site sends such a request directly to the intended site, its request will not be in the session of the end-user of the attack. Therefore, it will receive a different CSRF 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

The following Money Transfer Application built on top of spring boot ( a framework for bootstrapping and developing new Spring applications) framework.

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.