Synchronizer Token Pattern

-

This blog post will be explaining about how Synchronizer Token Pattern can be used to prevent CSRF attacks.

What is Synchronizer Token Pattern?

Synchronizer Token Pattern (STP) is a technique that uses a token (unique secret value) for each request. This token is embedded in all HTML forms and verified on the server side. Because of this random value, an attacker will not be able to place a correct token in their forged request, thus making them unable to perform CSRF attacks.

How does it work?

To explain how Synchronizer token patterns work, let us take a look at the following example (Source code can be obtained here).
STP example web application

Upon running the web application, we are greeted to a login page, we login using the hardcoded credentials:
Username : user
Password : csrf1

Before continuing with the flow let us take a look at the token class implemented as shown below:
Token class and its methods

As shown above, the token class has three methods implemented in it:
  1. GenerateToken : This method generates a random value using OpenSSL pseudo random bytes. the randomness of this value is further enhanced by base64_encode and the resulting value is set as the token.
  2. ObtainTokenByID : This method takes the session ID of the current session and searches for the token stored in the server side. It finds the token that is mapped to the session ID and return it.
  3. CompareTokens : This method compares the received token from the form with the token stored in the server side. 
When we enter our login credentials, the following actions are performed:
Actions being performed upon login

As seen in the above code section, when the user enters their credentials and logs in, a session identifier and it is set as a cookie named sessionID in the browser. 
At the same time a token is generated using the generateToken() method of the token class. The generated session ID and token are mapped together and stored in the server side in a text file (tokens.txt).
Session IDs and their corresponding Tokens saved in the server side

After the token is saved in the server side, we will be redirected to the update status page.
Update status form

In the above screenshot we can see the sessionID cookie is set with its value containing the session identifier. This page contains a POST form which asks for a status input. It also contains a hidden form which will contain the value of the token corresponding to the session ID.
In this example we have implemented an endpoint which accepts HTTP POST requests and responds with the token. The code below shows how the token is received using an Ajax call.

Update Status page source code which contains hidden token

Endpoint which responds with the token
As seen above, the endpoint obtains the token by calling the obtainTokenByID method in the token class, which extracts the token which is mapped to the current session from tokens.txt.

In this session our session ID is "09nik6iq9lkhl4liiu9apfef46". The figure below shows which token is mapped to this session ID in tokens.txt. This token is called in using the above shown Ajax call and inserted into the hidden token form.

Token mapped to the current session ID

Token added as the hidden field value

Once we write a status and submit the form, the next page will compare the submitted token value with the token stored in the server side by calling the CompareTokens() method in the token class:

Comparing tokens and displaying either a success or error message

The two tokens are compared and if they match, the page will display a success message. If they do not match, the page will display an error message.
Success Message
Error Message



My next blog post is a similar presentation of how the Double Submit Cookie Pattern can be used to protect against CSRF attacks. It can be viewed here.









Comments

Post a Comment

Popular posts from this blog

Double Submit Cookies Pattern

-
Image
This blog post will be explaining about how Double Submit Cookie Pattern (DSCP) can be used to prevent CSRF attacks. What is Double Submit Cookie Pattern? Similar to Synchronizer token Pattern this also uses a random token value, but unlike in Synchronizer Token Pattern where the token is saved in the server side, Double Submit Cookie Pattern does not save the token. Instead, it sets the CSRF token as a cookie and retrieves this cookie value and inserts it into a hidden field in each HTML form sent to the client. When the form is submitted, the submitted token value is compared with the cookie token, and if they are the same, the form is allowed to submit.  Because of this random value, an attacker will not be able to place a correct token in their forged request, thus making them unable to perform CSRF attacks.  How does it work? To explain how Double Submit Cookie Patterns work, let us take a look at the following example (Source code can be obtained ...
Read more

Cross-Site Request Forgery (CSRF)

-
Image
Cross-Site Request Forgery (CSRF) is an attack that takes advantage of users who are already authenticated in a web application by making them perform unwanted actions in that application. An attacker can trick the users of a web application by sending a link via email which executes a hidden action. CSRF attacks are not useful for data theft, since it targets state-changing requests meaning the attacker cannot see the response of the forged request. But the attacker make the victim unknowingly perform various actions like changing their login information, transferring funds etc. How does it work? To explain how a CSRF attack is carried out, let us take a look at a simple example. Bob wants to transfer Rs.7000 to Alice through HNB bank's online transaction portal. To do so Bob authenticates to the bank's website using his credentials. Eve is the attacker in this scenario and she plans on using a CSRF attack to get money transacted to her from Bob. To do this successf...
Read more