Cross-site Request Forgery Protection in web application via Double Submit Cookies Pattern

Cross-site Request Forgery Protection in web application via Double Submit Cookies Pattern

In the previous blog, I wrote about Cross-site Request Forgery (CSRF) Attacks, and how to protect a web application from CSRF Attack using Synchronizer Token Pattern. In this blog I am going to write about Double Submit Cookies Pattern which also helps to prevent from CSRF Attacks.

This is another way to implement Cross- Site Request Forgery protection through Double Submit Cookies Patterns.

Earlier in Synchronizer Token Patterns, there is only one cookie in the client side, which is known as the "Session Cookie". But in this Double Submit Cookies Pattern, there are two cookies namely "Session Cookie" and "csrf Cookie". And also there is another difference between Synchronizer Token Pattern (STP) and Double Submit Cookies Pattern. It is in the STP, had a thick server and a thin client. But in the Double Submit Cookie Pattern there is a thin server and a thick client. Depending on the requirements of the user, the user can select and  approach what ever they want.

But the main difference between the STP and Double Submit Cookie Pattern is both uses the CSRF token and the Session ID in-order to validate a session. So, these both are saved in server side storage for STP and in Double Submit Cookie Pattern they are stored in the browser as browser cookies.

Definition of Double Submit Cookie Pattern

When a user authenticates to a site, the site should generate a cryptographically strong pseudo-random value and set it as a cookie on the user's machine which is separated from the session ID. The server doesn't have to save this value in anyway. That's why this pattern is also known as "Stateless CSRF Defence". 

Then, the site requires that every transaction request which includes this random value as a hidden form value. Then the attacker can read any data which is send from the server or modify cookie values from the same- origin policy.

In order to mitigate this technique, the client need to just retrieve the CSRF cookie from the response and add it into a special header to all the requests. The following client workflow diagram (Figure. 1) represents how the process has been doing in the client side.

Figure. 1
Client workflow
Image credit - https://dzone.com

Compared to the job of the client, the job of the server is little more complex. The server need to create the CSRF cookie and for each request asking for a protected resource. Finally, it checks that the CSRF cookie and the CSRF header of the request are same. If it coincides it leaves, else it outputs an error message.
The following Server workflow diagram (Figure. 2) shows the above scenario.

Figure. 2
Server workflow
Image credit - https://dzone.com

The following are the brief contents of the Double Submit Cookie Pattern and it is shown in the following (Figure. 3)

Figure. 3
Image credit - https://www.owasp.org

• Attacker sends payload through victim's browser.
• Browser automatically includes user's identity.

As I have mentioned earlier, this pattern doesn't need server in order to store the tokens in the memory. So, when the client validates himself, the server will automatically generate a cookie and this will be send with the client when there is a success login. At this time, the server generates a cookie with a new CSRF token.

Quickly, the client receives the CSRF token, the client injects this token to a hidden field in its DOM ( Document Object Model). Next, after attaching this token value to each requests and this can be send to the server. Token value has two parts; one is presented in the cookie and the other is in the request body. Finally, when the cookies are presented in the browser, the client sends all the details to the server with the presented requests.

When this request is received, the server will get the token values which are presented in the cookie and in the request body. Then, it will compare the values and if they are matched, the corresponding response will be send back to the client. Else, the server shows an error message. 

The following (Figure. 4) shows the Simple CSRF protection. (Server side is not included in this diagram)

Figure. 4
Image credit - https://www.owasp.org

In order to understand the concept more clearly I wrote it as follows. In Double Submit Cookie Technique, we send a random value in both a cookie and as a request parameter, with the server verifying if the cookie value and request value match. When a user visits (Even before authenticating/ login, to prevent CSRF attack), the site should generate a cryptographically strong, pseudo random value and set it as a cookie on the user's machine which is a separated thing from the session identifier. The site then requires that every transaction request must need to include this pseudo random value as a hidden form value. 

If both of them match at server side, then the server accepts it as legitimate request. And if they didn't match, it would reject the request.

There is a belief that this above mentioned technique will work. Because, a cross origin attacker can't read any data which is sent from the server or modify cookie values. 

The drawbacks associated with this assumptions are: The problem in "Trusting of sub domains and proper configuration of whole site in general to accept HTTPS connections only".   

For the demonstration purpose, I have created a sample web application using PHP, which includes the Double Submit Cookie Pattern for the protection of CSRF Attack.

During login, the session identifier and CSRF token will both be generated and set as a cookie in the browser side. After the successful login, it redirects to Updating User page. There the user can input the details and update it. When the user click the "Update" button, the form is submitted to the action. There CSRF token cookie and form body CSRF token value will be submitted.

 In the web page, the CSRF token cookie and the message body will be obtained. Soon after, the web page compares these received two values and if they both matched it displays a success message. Else it displays an error message.

The following (Figure. 5) shows the comparison between the two received token values, which is presented in the "update.php" in my sample web application.

Figure. 5

Although there are many protection against CSRF Attacks, but still what happens when the attacker can set the CSRF Cookie? 

In order to get the answer for this question, I cam to know that there are more vulnerabilities presented regarding this. Let's see what are they.

1. Man-in-the-middle HTTP connections
2. Exploiting the sub domains
3. When proper mechanisms are not implemented against XSS (Cross-Site Scripting) 

Demonstration of the Web Application

The following is the screen shot of the Admin Login Page, which is shown in (Figure. 6).

Figure. 6

Next, after the Login (Username - admin, Password - password) was successful, it redirects to an interface known as Updating User in order to input the First Name and Last Name. After inserting the details, if the user click the "Update" button, it shows a success message as " Updated Successfully !". The following screen shot (Figure. 7) shows the success message.

Figure. 7

The source code for the above mentioned web application is presented in GitHub. 

I think, that's all you need to know about Double Submit Cookie Pattern. Hope you all enjoyed and understand it. See you all soon with another new interesting topic.