Cross-site Request Forgery Protection in web application via Synchronizer Token Pattern

Cross-site Request Forgery Protection in web application via Synchronizer Token Pattern

Even the most experienced CIO (Chief Information Officer) and web security experts need to protect themselves against attackers. So, not only them, all need to know about the security vulnerabilities available in the web applications, in order to protect ourselves from these vulnerabilities. There are many security vulnerabilities available in the web applications. Such as SQL Injection, Cross Site Scripting, Broken Authentication and Session Management, Insecure Cryptographic Storage, Cross Site Request Forgery are some of them.

In this blog, I am going to briefly describe about Cross Site Request Forgery Attack and how we need to protect our web applications using Synchronizer Token Pattern and Double Submit Cookies Pattern. 

First, let's see What Is Meant By Cross Site Request Forgery (CSRF) Attack.

CSRF is an attack and the expansion form of it is "Cross Site Request Forgery". It is also known as XSRF, Sea Surf or Session Riding. During the CSRF Attack, an unwanted action happens in the application by tricking the web browser, when the user is an authorized person.

A successful CSRF attack can be harmful for both the user also in the business field. Because, in the business sector, it damages the client relationships, helps in unauthorized fund transfers. At the next sector for the users, it affects as follows. When the criminal steels the session cookies, then the criminal might change the passwords and the information which are presented.

CSRF are mainly conducted using malicious social engineering. The following sample helps to clearly understand about this malicious social engineering which take place via CSRF. Sending an email or link in order to tricks the victim by sending a forged request to a server. As the user is new or unknown, the user clicks this malicious link/ email and this leads to an attack. This happens because of the unawareness of the user and also at the same time, the user is unknown to distinguish the legitimate request which came from the criminal.

The following diagram (Figure.1) briefly helps to get an idea about CSRF(Cross Site Request Forgery) Attack.

Figure. 1
Image Credit - www.imperva.com

Example for a CSRF(Cross Site Request Forgery) Attack

For an example, if a criminal needs to get a $100 to his own account, unless the same $100 which is really owned by Bank. The following is the typical GET request the hacker modifies in order to get the money. Now the malicious request is looked as follows (Figure. 2).

Figure.2
Image Credit - www.imperva.com

But, in this above scenario, if it is GET request, then probably it carries the request parameter which is appended in the URL string. If it is presented in the URL string, then it can be seen clearly when exchanging the data. So, the culprit change the same above code into unnoticeable look which uses the POST request. In the POST request the same above code is embedded inside, which is not noticeable. 

Figure.3
Image Credit - www.imperva.com

This above POST request have this same malicious request, which uses <a> href tag. So, the attack can be easily achieved in a <form> tag with automatic execution of the embedded JavaScript. The above image (Figure. 3) shows the sample of the form.

By this, now the attacker can distribute through email to a large number of Bank Customers, and while they are (Bank Customers) already logged into their own bank accounts, without their knowledge i.e unintentionally, the $100 is transferred to the attacker's account.

Mitigation methods of CSRF Attack

1. Log out from the web applications when not in use.
2. Securing the username and passwords.
3. By not allowing the browsers to remember the passwords. (Not using the cookies)
4. Avoid simultaneously browsing habit when, already logged into an application.
5. By generating unique random tokens for every session request / ID.
6. Present CAPTCHA s, which alert unwary users.
7. Use "IncapRules" which helps to create a policy that filters the requests to sensitive pages and functions based only on client HTTP referrer header content. 
8. Verifying the same origin with standard headers.
9. Challenge / response pattern.
10. Use encrypted token pattern.

To block the CSRF Attacks, Double Submit Cookies Pattern and Synchronizer Token Pattern are used.

Now lets see what is meant by Synchronizer Token Pattern. 

Synchronizer Token Pattern (STP)

Synchronizer Token Pattern (STP) is mainly verified on the server side, where a token, secret and unique value has been there for each request. These all are embedded inside the web application in HTML forms.

In order to maintain the uniqueness, a token is generated by the server. In this above mentioned process, the server generates the token per every session. In this case only, the authorized user can authenticate. Because, the attacker is unable to place the correct token in the request to get himself authenticated.
The original intention of this Synchronizer Token Pattern was to detect duplicate submissions in forms.

In STP, the cross domain AJAX calls are not possible. This clearly states that all need to be under same domain, in order to perform a CSRF attack. So, the third party attacker cannot perform a CSRF attack.

For an example, if the victim is in banker.com and the attacker is in attacker.com, then cannot request the CSRF token from the server via an AJAX, because the domain doesn't match each other and they both are in different domains.

Synchronizer Token Pattern - How it works?

The following diagram (Figure.4) briefly explains about the Synchronizer Token Pattern with a flow diagram.

Figure. 4
Image Credit - www.cybrary.it

In this above diagram:

1. User sends GET request to a server.
2. Server sets the cookie with session-id, and save the session data with the token.
3. Containing token in a hidden field, the server returns HTML with a form.
4. Next, user submits form, along with a hidden field.
5. Finally, the server compares the token from the submitted hidden field form, with the tokens which are already saved in the session storage. If both these tokens match, this means that the form is submitted by the authenticated user. Else it concludes that they came from attacker / from some other third party personals.

Advantages of Synchronizer Token Pattern (STP)

• Simple to implement.
• Able to works with forms and AJAX.
• Cookie can actually be HTTP only.

Disadvantages of Synchronizer Token Pattern (STP)

• Any AJAX POST s must also include the value.
• All forms must output the hidden field in HTML.

For the demonstration purposes, I have build a simple web application using PHP, to clearly understand about the Synchronizer token pattern. In this developed web application, after the successful login the valid user can input the first name and last name.
First, in order to login into the demo web application, the hard-coded login credentials are as follows. (Username - admin, Password - password)  

The login credentials are submitted using a POST method. After the server validates the authenticated user on login process, the server generates the session ID and CSRF token. Finally, at the same time as the browser cookie, the generated session ID is used. The following figure (Figure. 5) shows the generated session ID, CSRF token and POST method.

Figure. 5

The cookie with session ID and CSRF token are send to the server, when the user enters the data and submit the form,  This part is done as a hidden input field. The following figure (Figure. 6) shows us the hidden input field.

Figure. 6

After the user logged in, the browser sends an AJAX call, in order to get the CSRF token. This AJAX call, contains the session id. This part cannot be seen by the user, when the page loads. The following figure (Figure. 7) shows the tokens are embedded inside the hidden field, while submitting the form. 

Figure. 7

Next, when the user clicks the "Update" Button the POST request is send. Finally, the server validates the session id and CSRF token. If it is a valid token then the server accept it, else rejects it.

Demo Web Application

The source code for this Demo Web Application for Synchronizer Token Pattern is available in GitHub.

Screen shots for the Demo Web Application

The following screen shot (Figure. 8) shows the Admin Login Page of this Web Application.

Figure. 8

Next, the screen shots (Figure. 9) shows the Updating User details. 

Figure. 9

Finally, after the valid user input the First Name and Last Name, it is updated. And the screen shot (Figure. 10) can be seen below. It shows a message like " Updated Successfully ! ".

Figure. 10

I hope that you all can able to understand about Synchronizer Token Pattern and lets talk about Double Submit Cookies Pattern in the next blog post. Hope you all enjoyed it.