Double Submit Cookie Pattern

Previously, I have discussed the Synchronizer Tokens Pattern as one of the solutions for the Cross Site Request Forgery attack on Web Applications.

This blog post will discuss Double Submit Cookie Pattern to prevent from CSRF attack.

What does it mean?

Double submitting cookies is defined as sending a random value in both a cookie and as a request parameter, with the server verifying if the cookie value and request value are equal.

How does it work?

When a user authenticates to a site, the site should generate a session identifier and set a cookie in the browser. At the same time, it generates the cryptographically strong random value or the CSRF token for the session and set it as a cookie on the user’s machine separate from the session id. The server does not have to save this value in any way, that’s why this pattern is sometimes also called Stateless CSRF Defense.

The site then requires that every request include this random value as a hidden form value (or another request parameter). A cross-origin attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy.

In the case of this mitigation technique the job of the client is very simple; just retrieve the CSRF cookie from the response and add it into a special header to all the requests.

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 screen

                                                                     Login html post req

This login form submits user credentials using a POST method. if the user is authenticated successfully, server-side will creates a unique Session-Id and the CSRF token but the server only stores the Session-Id. Importantly server doesn't store CSRF token in this scenario.

Then the server will response the corresponding CSRF token along with the response body. After that generated session id & server respond CSRF token set as cookies in the browser.

In here we must set the httponly flag “false” because js should able to access the csrf token cookie to add to the hidden field in the post request.

                                             Cookie setup code segment

                                                                 Stored CSRF token              

Then after user will redirect to user status update page. In this page, I have implemented an AJAX call(self-call) to get the stored CSRF token from the browser cookies.

                                                      Ajax call

Then the corresponding CSRF token added to the hidden field.

                                                 Hidden field with value

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 the cookie header for session id and also server compares CSRF token from request body(hidden field value) against CSRF token from the header cookie. If these tokens matched then server accepts the request.

                                                Accepted request

How we can say the method is safe?

Cookies are sent automatically with every request, regardless of whether the request was initiated by the original site or by a third party site. That’s why a cookie alone does not suffice as every request will contain it.

But by having the token also in the request itself, an attacking site cannot generate valid requests any more as they can’t get hold on the user’s token.

Conclusion

 

The Double Submit Cookie Pattern techniques described in this story are viable and worth a thought for any application that contains useful data.

 

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.