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

Cross-Site Request Forgery Protection Using Double Submit Cookies Pattern

Previously we have discussed what is cross-site request forgery, how it works and one solution ( synchronizer token pattern) for this kind of attack that we can implement. Now I'm going to explain the second solution called as double submit cookies pattern. If you don't have any idea about this CSRF attack, before read this post please read about CSRF from my previous post. 

Link is here - How CSRF works?

Now we are moving to see the process of double submit cookies pattern.

If storing the CSRF token in session is problematic, an alternative defense is use of a double submit cookies. A double submit cookie is defined as sending a random value in both a cookie and as a request parameter, with the server verifying if the cookie value and request value match.

In this method the difference is when user logs and authenticates in to his bank account (previous example), the bank site should generate a ( cryptographically strong) pseudo random value and set it as a cookie on the user's machine separate from the session id. The site (server) does not have this value in any way, thus avoiding server side state.The bank site then requires that every transaction request include this random value as a hidden form value (or other request parameter). A cross origin attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can force a victim to send any value he wants with a malicious CSRF request, the attacker will be unable to modify or read the value stored in the cookie, Since the cookie value and the request parameter or form value must be the same, the attacker will be unable to successfully force the submission of a request with the random CSRF value. 


Flow of CSRF Double Submit Cookies Pattern

1. User log in to the website, along with this, server generate a CSRF and set it as a cookie in the web browser, and also the session the session identifier.
2. Client, the web browser will exact this CSRF cookie value and set the same value in a html form hidden field by modifying the DOM.
3. So when the form is submitting to the server for processing, the CSRF cookie along with the hidden value from the html form with the same value as the CSRF cookie will go in the request.
4. Server will validates this two values and process the request, if and only if these two are match with each other. Otherwise, server will discard the client request.

For demonstration purpose I have developed a sample for this double submit cookies pattern. 

This can explain by using my sample code.

User login.

In first step server will validate the user login credentials which are coming with the user login form and create a new CSRF token as well as session cookie with the session id. Then the CSRF token will set as a cookie in the client's browser.  

In here CSRF cookie named as a "CSRF_Token" and the session cookie named as a "Session_cookie".

When this cookies reached to the client, client's script will find this each cookie value and set the CSRF cookie value in a hidden field of a html form by modifying the DOM.

In here for extract the CSRF cookie I used a javascript function and also JQuery for modify the DOM.

Now client side (browser) work load is done and client send the request to the server. ( any state changing request).

When this request comes to the server side, server will get the cookies. For that purpose server used "getCookies" function.

  

Its time for sever to validate/compare above collected cookies values. ( value in the hidden field with the cookie value)

If the above mentioned two cookie values match, server will accept the request and ensure that it comes from real user.

You can download this sample code from my git-hub account and see how it works. All introductions are provided with it.

Link is here - CSRF-Double-Submit-Cookies Pattern