Cross-site Request Forgery (CSRF) Protection - Part I

Cross-Site Request Forgery Protection Using Synchronizer Token Pattern

What is this cross-site request forgery

Simply cross-site request forgery is a web based attack. We can call it as one-click attack or session ridding attack. I can explain it like this. Think, there is an end user interact with his bank web site. Now he is login to bank web site for do some transaction with his account. At the moment bank gives him a session token. 

Session id is a kind of a permission that allows authorized users to interact with web services within predefined time period. Those session tokens are provided by above mentioned web services. This session token helps to identify authorized users and their activities. Those session id is stored in a cookie. We will look at this cookies in later.

Back to the topic, when the user interact with the bank, this session id goes along with the each and every request (get,post,put,delete). Now there is an attacker who wants to log into above person's bank account and want to transfer money from that person's account. For that he send an email to that person with the malicious link that looks like it comes from another domain. But actually it is redirecting to the bank. Now authorized user click on that link and it goes along with previous valid session id. In this moment above malicious code will execute and perform the task that is transfer money to attacker's account. 

This is the background scenario of cross site request forgery.

Cookies

A cookie is a tiny file that's stored on your web browser It contains the address of the web site,session id,path, etc and codes that your browser sends back to the web site each time you visit a same page there. Cookies don't usually contain personal information or anything dangerous, they're usually innocuous and useful.

The main purpose of a cookie is to identify users and possibly prepare customized web pages for them. When you enter a website in first time, it may be asked to fill out a form providing such information as your name and other information as well. after we submitted that form server will create a cookie for that web site we are logged and sent to your browser which stores it for later use. The next time you go to the same website, your browser will send the cookie to the server. The server will validate the session id that we are discussed in earlier , and also other attributes such as path, domain, etc as well. In here user can log into same website without filling same form which has already filled in earlier, it redirects directly to the web site welcome page .

Now we are know about the CSRF attack. Then the next thing is implement the countermeasures. For this problem. There are two solutions.

1. Synchronizer token pattern
2. Double submit cookies pattern

In this blog post I'm going to discuss about Synchronizer token pattern.

Synchronizer token pattern

Instead of using session id now we are used CSRF token or we can call it as a anti-forgery token for more secure purpose. 

What are this CSRF tokens?

CSRF token is a another kind of  random authentication token which is included in web request as a hidden field. Those tokens are only send with POST,PUT,DELETE request.

Lets see how it works.

The client request an HTML page that contains a form. In server side they have some URL which is anybody can call it and get the CSRF token. When client logging to that web site, server will generate the session cookie as well as session token/CSRF token and keep it in the server. Now server includes two tokens in the response for client. One token sent as a cookie. The other is placed in a hidden form field. The tokens are generated randomly so that an adversary/attacker cannot guess the values.

When the client submits the form, it must send both tokens back to the server. The client sends the token as a cookie, and it sends the CSRF token inside the AJAX code ( A browser client automatically does this when the user submits the form.). If the request does not include both tokens, the server disallow the request.

What is this AJAX code?

AJAX code is a set of web development techniques using many web technologies on the client side to create asynchronous web applications. AJAX stand for Asynchronous JavaScript And XML.

There are four main different usages of the AJAX code.

1. Update a web page without reloading the page
2. Request data from a server - after the page has loaded
3. Receive data from a server - after the page has loaded
4. Send data to a server - in the background

Among those usages, synchronizer token pattern uses fourth one, send data to a server - in the background.Whenever our page is load it is making this AJAX code. It happens without refreshing the page.Along with this AJAX code our previous session cookie will go to server and server have to validate the session cookie. If it is valid, server will give us a CSRF token. Now when our page load AJAX code will run and get the CSRF token.That token will be added to the page source code (body or header). 

When the user make any POST,PUT,DELETE request to the server, server will validate the session cookie first and checks request body or header to validate the CSRF token. That token should be belong to same session id. Only these conditions are true server will consider this request as a valid request.

Lets see why it cant be do with an attacker.

Assume that attacker has our session cookie and he sends an AJAX code with that session cookie to server. Obviously session cookie will go if that request is made. No hesitation about that. But the problem is attacker do this request within different domain. So the thing is cross domain(different domain) AJAX codes are not possible. Because of that server will discard the request.

Now we are know about how synchronizer token pattern works.

This is the correct flow of synchronizer token pattern and I have developed a sample of  synchronizer token pattern.

You can download full source code from my git-hub account.

Link is here - CSRF - Synchronizer token pattern.