CSRF Defence - Synchronizer Token Pattern

This is the continuation of previous blog post CSRF. If you didn't read it, please read it first because concept of CSRF attack is described there.
As I mentioned in earlier post, there are 3 CSRF prevention mechanisms. Synchronizer Token Pattern is one of that.

First I will explain how some person log into system and do some work within the system.
As the first step, user will log into the system using login screen. That is the place where authentication happen. After giving correct user credentials (Username and Password), System will give the permission to access protected area in the system. Now the system know who is the logged person. But there is a problem. That is because we are using HTTP (Hyper Text Transfer Protocol) in web applications and it is not statefull protocol. So we need to keep maintain state of the logged person in the system. This is the place where cookie comes into play.  😏 (🍪 Not the cookie we eat). Cookie is a small data item stored in the web browser. So we can store some information in them and can be used to maintain user session state.

As the diagram shows, when user log into system, system will create session ID to uniquely identify a user and send it as a cookie to web browser of the user. To make communication statefull, session cookie also send along with each client request. So server know who sent that request by reading session ID in session cookie sent by user.

Now let's move to the topic, CSRF - Defense using Synchronizer Pattern. So we have to enhance above scenario to make it protected from CSRF attacks.

Red colored items are newly added content to make this system protected from CSRF attack. Now I will explain that extra process. As I mentioned in first scenario, Server will create a session ID for each user that logged into system. In this scenario, at the same time that session ID created, we create another unique token called CSRF token and store that with mapping to session ID. So in server we have to maintain session ID and CSRF Token of every logged user. Even-though CSRF Token created when session created, it won't sent along with the home page loading time. So client needs to request it using another request. It is an AJAX request. After getting the token, it will append into the web page client currently viewing. Usually pages that needs CSRF protection has HTML forms because there should be user data needs to make requests. The CSRF token taken from AJAX request will added to the HTML form as a value of a newly appended hidden field. It will looks like below.

<form method="POST" action="/friends">
    <input type="text" name="newfriendname"/ id="newuser"/>
    <input type="hidden" name="CSRF_TOKEN" id="csrf" value="sdiufyw786tr32wrsfsa"/> 
    <input type="submit" value="Add Friend"/>
</form>

Above form will request this POST request.
URL                        - https://facebook.com/friends
Body Parameters     - newfriendname=Robert&CSRF_TOKEN=sdiufyw786tr32wrsfsa

So, how this method protects from CSRF attacks? Its simple, because hacker does not know session ID of the user, he does not know CSRF token of the user. hacker can force John to make this POST request.
URL                        - https://facebook.com/friends
Body Parameters     - newfriendname=Hacker

But where is CSRF_TOKEN parameter. Hacker does not know it. Server will not execute request without or wrong CSRF_TOKEN value. Then hacker cannot send the malicious request. So we have defended the CSRF attack.

This is the end of this post. If you have any suggestions, questions, confusions, feel free to add comment. I will reply as soon as possible. Thank you for reading :-)

Nishan Sajeewee