CSRF – Renu Harshatha

This blog will discuss about Double Submit Cookie which is the second prevention mechanism of CSRF attack. If you are not aware of CSRF attack and how it works read my previous blogs regarding it.

In the last blog we discussed about Synchronizer Token Pattern, and I mentioned it holds a drawback when there are more login sessions because the server will store the CSRF tokens against the session IDs which might lead overload in the server. This is where the Double Submit Cookie(DSC) comes in play. In DSC, server doesn’t store the token. This is why DSC is also called as Stateless CSRF Defense.

How it works

The above diagram shows how the client browser logs in using the credentials meanwhile a session is created and the session ID is set as the cookie in the client browser.

Next, the server sends the CSRF Token as set cookie header to set the cookie, User access the feedback page which was sent as a response. The CSRF token is extracted from the cookie header and append the Token as hidden file (either in the head or body). Form is submitted along with the CSRF Token and CSRF Cookie.

Server compares the CSRF cookie and the submitted token through the form. If both the are equal the next action is performed else the error message is sent.

For better understanding of this A simple HTML,JavaScript and PHP project is done.

The UN and Password is hardcoded as anony@gmail.com and gT$0om

1.Login with the credentials

Client uses their credentials to login.The server generates Session ID and set it as cookie also generates CSRF Token and store it in a cookie. The following code shows how the token is generated

The server generates the session ID and Token, The token is generated with the help of openssl_random_pseudo_bytes which use to generate random numbers. These random numbers are encoded in base64_encode so that it will be hard to read even when intercepted. The client is redirected to the feedback page to give their thoughts.

2.Feedback Form sent as response along with Set-cookie Header

The above code is same as the form created in Synchronizer Token Pattern, the token should be sent in a hidden field, but the function created is to get the CSRF Token from the Cookie which was received from server.

Take the cookiename as parameter (cname). Create a variable (name) with the text to search for (cname + “=”). Decode the cookie string, to handle cookies with special characters, e.g. ‘$’ Split document.cookie on semicolons into an array called ca (ca = decodedCookie.split(‘;’)). Loop through the ca array (i = 0; i < ca.length; i++), and read out each value c = ca[i]). If the cookie is found (c.indexOf(name) == 0), return the value of the cookie (c.substring(name.length, c.length), else return “”. If you need further more details on cookies in javascript look in this.

This source code checks both the cookie and the token are same. If both are equal the next necessary action will take place else denies. This is how the DSC helps to prevent CSRF attack.

The most frequently asked question is “Is the web application safe now?”, I would say “It is partially safe”, DSC is an solution for the drawback in Synchronizer Token Pattern (STP) which might overload the server as the Session IDs and the Tokens are stored in the Server Database. Cookies with sensitive server metadata should be tagged as HTTPOnly flag but in DSC the cookies aren’t tagged in that way, next if the subdomains have potential XSS vulnerabilities it might affect the upper domains. We have to make sure that the web application is XSS-resistant if the application is in the sub domain.

In order to learn more about these, check out this presentation.

Last blog covered the topic on what is CSRF and how it works. This blog is the continuation of CSRF attack prevention. Synchronizer Token Pattern is one of the main solution for the CSRF attack.

What is STP?

It is a CSRF prevention technique where a “token”, which is a secret,unique value for every request is embedded within the web application ( in HTML Forms which is verified on the server). It was able to see that CSRF attacks only targeted state-changing requests. Since there is no way to see the response to the forged request,data theft cannot be done.

Prevention

Generate a random string in server side and append it to the body of the front end. Check both values when user submit web page.

The above diagram shows how the STP is used in HTML POST Forms to prevent from CSRF attack. The Token stored in the server and Token in the hidden file are compared to check whether both are same, so that the next action could perform. By implementing this prevention method, The CSRF attacks which are done through POST method by the attacker is blocked.

For better understanding of this A simple HTML,JavaScript and PHP project is done.

The UN and Password is hardcoded as anony@gmail.com and gT$0om

1.Login with the credentials

Once the client logs in with their credentials, a session ID is created then they are redirected to the feedback form.

2.Feedback Page sent as response

You can observe that there is a hidden input in the source code of the feedback form below without a value. The CSRF token will be set as the value as soon as the response is given to the ajax call.

To exchange data with a server in the backend, XMLHttpRequest object is used. (To know about XMLHttpRequest visit https://www.w3schools.com/xml/ajax_xmlhttprequest_create.asp )

open() and send() is used to send the request to the server, these are the methods of XMLHttpRequest

onreadystatechange	Defines a function to be called when the readyState property changes
readyState	Holds the status of the XMLHttpRequest.

Ajax call is sent to request for a token in the server, In my project I have used a separate PHP file to generate the token.

3.Creation of Token

Token which is generated should be a random number therefore, openssl_random_pseudo_bytes is used to generate random numbers. These random numbers are encoded in base64_encode so that it will be hard to read even when intercepted.

The generated token is stored as a Session Variable and written in the text file, to identify the token, the session ID is stored along with it. To write in the text file

Once the file is written, the Session token can be sent as a response to the Ajax call.

4.Token stored in Hidden File

5.Token Comparison for Validity

Comparing the stored token with the received token

If the form is from the genuine website, it would have the hidden token and it would be successfully validated. Although STP prevents CSRF attack it has its drawback which is, the need to store token and session pair for each user in the server. This might overload the server if there are too many users logged in. (Remember the validation is done in the server side). Double Submit Cookie helps to overcome this drawback.