Synchronizer token pattern

Today I am going to explain the Synchronizer Token Pattern in this blog post as one of the identified solutions for this CSRF security attack.

What is Synchronizer token pattern?

 

Synchronizer token pattern (STP) is a technique where a token, secret and unique value for each request, is embedded by the web application in all HTML forms and verified on the server side. SPT is using to preventing CSRF attacks from the attackers. Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data since the attacker has no way to see the response to the forged request.

How to prevent?

To prevent CSRF attacks we can use a simple method such as generating a random string in server side and append it to the body of the front end and check both values when user submit web page. also, we can use methods such as Check standard headers to verify the request is the same origin.

Synchronizer (CSRF) Tokens

• Any state changing operation requires a secure random token (e.g., CSRF token) to prevent CSRF attacks
• Characteristics of a CSRF Token
• Unique per user session
• Large random value
• Generated by a cryptographically secure random number generator
• Add token to the session and check it in the backend
• The CSRF token is added as a hidden field for forms or within the URL if the state changing operation occurs via a GET
• The server rejects the requested action if the CSRF token fails validation

Let’s look a sample project,

This application is developed using PHP & JS.( Github link - click here)

First, you need to login to the application by entering username and password. For the demo, I have hardcoded the credentials(username: admin, password: pass)

                                                            Login page         

This login form submits user credentials using a POST method. if the user is authenticated successfully, a unique Session-Id and the CSRF token will be created along with this session and at the same time generated session id set as a cookie in the browser.

CSRF token is stored against the session identifier at the server side. you can see the stored CSRF token in the project text file,

Here, after the user logged in, the browser will send an Ajax call to get the CSRF token to csrf_token_generator.php. This Ajax call contains the session id. Then the server will response the corresponding CSRF token along with the response body.

This is where token embeds into a hidden field on form submit.Used openssl_randon_pseudo_bytes() function in PHP to generate the 32bit long CSRF token.The generated value then converted into it’s base64 value using base64_encode() in order to make it more secure. User doesn’t see this is happening when page loads.

After page loaded,

I have implemented a POST request to update some user status. The post request contains this generated CSRF token and the session cookie.

When the user clicks “updatepost” btn the Post request send. Then the server validates session id which came from request header and CSRF token in the body.

If the token is valid server accept the request or if it is invalid server reject the request.

How we can say the method is safe?

Let’s says an attacker send us a link that contains post request hidden to update user status but attacker not able add the CSRF token to the attaker’s POST request. so the server will ignore the request.

The source link of the example: https://github.com/DeshanFernando/Synchronizer-Token-Pattern

 

Conclusion

The Synchronizer token pattern techniques described in this story are viable and worth a thought for any application that contains useful data.