Synchronizer Token Pattern

What is Cross-Site Request Forgery (CSRF)?

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted/state-changing actions on a web application in which they’re currently authenticated. With the help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing a state-changing operation like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.

Example

In order to execute an attack, we must first understand how to generate a valid malicious request for the victim to execute. Let us consider the following example: Sam wishes to transfer $100 to Kate using the bank.com web application that is vulnerable to CSRF. An attacker wants to trick Sam into sending the money to the attacker instead. The attack will comprise the following steps:

  1. building an exploit URL or script
  2. tricking Sam into executing the action with social engineering

If the application was designed to use GET requests to transfer parameters and execute actions, the money transfer operation might be reduced to a request like:

http://bank.com/transfer?acct=KATE&amount=100

The attacker decides to exploit CSRF attack using Sam as the victim. The attacker first constructs the following exploit URL which will transfer $100,000 from Sam’s account to the attacker’s account. Attacker takes the original command URL and replaces the payee name with attacker’s name and also raised the transfer amount:

http://bank.com/transfer?acct=ATTACKER&amount=100000

The social engineering aspect of the attack tricks Sam into loading this URL when she’s logged into the bank application.

  1. sending an unrequested email with HTML content
  2. planting an exploit URL or script on pages that are likely to be visited by the victim while they are also doing online banking

The exploit URL can be disguised as an ordinary link, encouraging the victim to click it:

<a href=”http://bank.com/transfer?acct=ATTACKER&amount=100000">Cute Puppy Photo !!</a>

<img src=”http://bank.com/transfer?acct=ATTACKER&amount=100000" width=”0" height=”0" border=”0">

If this image tag was included in the email, Sam wouldn’t see anything. However, the browser will still submit the request to bank.com without any visual indication that the transfer has taken place.

How to Prevent CSRF Vulnerability?

There are 2 types of patterns to prevent CSRF.

1) Synchronizer Token Pattern

2) Double Submit Cookies Pattern

In this blog post, we will look at how the Synchronizer Token Pattern prevents CSRF and how it can be implemented in a Java application. The following blog post will discuss Double Submit Cookies Pattern.

How does Synchronizer Token Pattern work?

In the end, the server not only checks the session ID corresponding to the username but also checks the CSRF token and only if both attributes are matched correctly the money transferring activity will take place.

Why does the attacker fail in this scenario?

Reason: Cross-domain Ajax calls are not possible.

Sample Application

Login page:

Basic user validation:

Once the authentication is successfully completed, the corresponding cookie will be generated and stored.

State changing operation (transferring the money from one account to another) page:

AJAX call is made and the retrieved CSRF token is embedded in the form.

Finally, if the POST request had the valid CSRF token then the server will return a success message.

The full implementation of this example can be found here.