Mitigate CSRF with Synchronizer Token


In the previous blog post about cross site request forgery AKA CSRF, I discussed about the basics about CSRF, what it does and some mitigation techniques.
Among those techniques, in this blog post I’m going to talk about the Synchronizer Token Pattern and its flow when exchanging CSRF token.

What is Synchronizer Token Pattern?

This is a technique where a unique secure string value, also known as a CSRF token, will embedded by the web application in all HTML forms and verified on the server side in each state changing requests. The token may be generated by any method that ensure uniqueness, unpredictability and security so that any attacker would not be able to place the correct token along with the request.

Why STP?

A third party attacker cannot perform a CSRF attack, because cross domain AJAX calls are not possible. This means, the victim is in banker.com, and attacker.com cannot request the CSRF token  from the server via an ajax, because the domain doesn't match each other, and cross domain ajax calls are not possible as I mentioned before.  



Now lets go in to the flow of this synchronizer token pattern when it comes to a state changing request.
  • First user will login to some website, for an example banker.com.
  • Upon login, the server will create the session identifier and set it as a cookie in the web browser.
  • At the same time, the server generate a CSRF token and map it to the session identifier. This means that the server generate a unique string/token to this particular session.
  • Whenever before a state changing operation, the webpage needs to submit the session cookie to the server and need to obtain the CSRF token allocated to that session, and this should be done only by executing an AJAX call (JQuery Ajax) via JavaScript.
  • So, after executing the AJAX call successfully, the webpage receives the CSRF token and need to modify its HTML form which is likely to be a POST request form, with this token value. It can be done by modifying the document object model (DOM) and adding a new hidden field with the value of the CSRF token value.
  • Now the request has been sent, and the server will validate the received CSRF token in the HTML form's hidden field with the CSRF token that the server stored within. And if and only if both the tokens are match, server will process the request. 

Let’s go through each of these steps with an example of a simple application.


First user logins to a website.

When user clicks on the login button, server will validates the user credentials and creates a cookie. Since I'm using Java as the programming language, a session cookie will create automatically in the browser, and its name is JSESSIONID and its value is the session identifier value. So i simply took this cookie value and map it to the CSRF token. 
   
(I created a variable called jsession at the top of the code)

So, the next step is to create a secure, unique and random seed/string or a token 😆. The function I created to achieve this is, 

Now, create a token and map it to the session identifier. I used Java Hashmap classes to map these values.

The HashMap class,

The mapping of the session id and the token,


Now the AJAX call.

Before comes in to AJAX call, Lets see how the server response to an AJAX call with the token mapped in the previously mentioned HashMap. 😄
I implemented a separate class to response AJAXs. Let's look at it.
   
So, in here server gets all the cookies and check whether if there is this "JSESSIONID" cookie which contains the session id. If its there, server will call the Map class which contains the HashMapped token and assign it to a JSON object which is compatible to AJAXs.
So this is the server's doing.😉

Let's see how the client or the webpage requests this token from an AJAX call, and add the token value to it's hidden field.

(The following image shows the javascript ajax call.)  

(The following images shows the HTML form.)
  


So, assume that everything is perfect and the AJAX call is done successfully, the HTML form's hidden field value is equal to the value of the received CSRF token via ajax. 😅


Now user perform the state changing operation which is a HTTP POST request according to above examples.



Along with this request, the CSRF token will be submitted to the server. Finally the server gets the session id and pass it through the hash map class that we created and get the corresponding CSRF token matching to this current session and validates the received token in the HTML form with it. If those two are equal, server will process the request.

      

So if all the validations are successful, the form will submit successfully. 😌
   


And, if you check the server logs, you can identify the session id's and CSRF token's behavior in each stage. 😊 
 


Anyways, for your own testing purposes, you can download this application from my GitHub account. 


  

Comments

Post a Comment

Popular posts from this blog

RMI (intro)

Image
What is RMI?  RMI stands for Remote Method Invocation. It is an application programming interface (API) that allows an object running on one Java Virtual  Machine (JVM) to invoke methods on an object running on another Java Virtual Machine (JVM), client server architecture is a good example where RMI is used. Basically, RMI provides for communication between programs written in the Java programming language. Architecture  In an RMI application there are two programs, a server side program and a client side program. Inside the server side program, a remote object is created and reference of that object is made available for clients. The client side program requests the remote object from the server to invoke its methods.  (A diagram to represent RMI architecture) Stub & Skeleton? Stub is a representation the remote object in the client and its acts as a gateway for the client program. Skeleton is the object that in the server-side. stub communicates with
Read more

Mitigate CSRF with Double Submit Cookies

Image
I previously explained what is CSRF  and how we can mitigate a CSRF attack using Synchronizer token pattern technique. In this blog post I'm going to talk about another CSRF mitigation technique called "Double Submit Cookies Pattern"  😉 What is Double Submit Cookies Pattern? This is a technique, that sends a random seed or a "token" as we call it, in both a cookie and as a request parameter, with the server verifying if the cookie value and the request value match. Why DSCP? Now its obvious that a third party entity cannot perform a CSRF attack without the CSRF token, and in here attacker or the third party entity cannot get the token because its in a cookie, and third party web pages cannot retrieve cookies from another web page that has a different domain. For example, assume that the genuine web page is banker.com, and the attacker's web page is attacker.com, when a user logged in to the banker.com, and accidentally redirect to attacker
Read more

Let's Configure HTTP'Secure' in Apache-Tomcat

Image
What is HTTPS?.. if you don't have any idea about what is HTTPS, refer my previous blog post about HTTPS . If you have an idea about HTTPS and SSL/TLS handshake, you are good to go 😊  Creating a digital  certificate We can create a digital certificate using "Java KeyStore (JKS)". This is a repository of security certificates. We can generate a keystore file using keytool command. in order to work with keytool, you must have "JAVA" installed in your computer.  keytool is a key and certificate management utility that allows users to administrate their own public/private key pairs, and the keystore file we are going to generate bellow will also be our local tomcat server's server certificate.   Options  When creating a "keystore", we need to provide some options and values to it. -genkey/-genkeypair -alias  -keyalg  -keystore  -keysize -validity -sigalg -storepass -keypass -dname  -genkey/-genkeypair -genkey
Read more