Cross Site Request Forgery attacks mitigation

Secure Software Systems

Author - Viraj Dissanayake

Ø Introduction

This article will be focusing on the understanding of the CSRF and the implementation of the mitigating these kind of attacks.

Ø Cross site request forgery

Before moving on to the Overview of CSRF attacks, make sure to have a clear idea of these terms

Ø Web applications

Web applications are the main target of CSRF attacks

Web applications are services which exposed by organizations on the internet

Most of the web applications rely on three components

§ The client – throughout this article we consider the browser as the client

§ The web server – forward the client requests to the application server

§ The backend – a database

Ø Client side HTTP methods(GET/POST)

GET – The most common request sent by the browser to request for content. All the parameters are send in query parameter

POST – Most of the forms use POST method to sed data. Parameters go separately to the server

Ø Cookies

Cookies stores stateful information for the stateless HTTP protocol

Cookies are mainly used for session management, personalization and tracking

A cookie mainly consists of name, content, domain, flags and the path

Ø HTTP flags –

HTTP only flag – by enabling this flag can stop executing scripts on client side from a different domain

Secure flag – this enables HTTPS protocol

Using the vulnerabilities of the web applications, an attacker can inject arbitrary javascript, SQL, HTML to pass the payloads and perform the attack. This is known as cross site scripting.

There is no need of having authenticated session, to exploit this vulnerability

Ø Overview of CSRF attacks

In Cross site request forgery attacks, the browser is tricked into making unauthorized requests behalf of the user. This could even happen without knowing by the user.

Let’s think that you are going to do an online money transfer. You log in to your bank’s website. At the meantime, assume that you have opened some other tabs in the browser and visits some websites. Unfortunately, one of them was an attacker’s website which contains a malicious script that instruct to transfer your money to different account on your submission of the money transfer.

If this HTTP request was a GET request, that will include two parameters according to this scenario. The amount that being transferred and the account

http://ABS_bank.com/transfer?amount=5000&account=your_account

in the attacker’s website he attached the malicious script to an image of that web page. When you click on that image the script gets execute, which transfer your money to different account without your knowledge.

If this request was a POST request, the attacker has to use a different approach. He has to use HTML form and hidden input fields to pass the parameters. To increase the possibility of the attack being successful, he can execute it on the page load. So it would get submitted even without your interaction.

</form>

We have discussed about XSS and CSRF attacks. Were you able you identify the difference between these two attacks?

As I mentioned earlier, XSS does not need to have an authenticated session, But the CSRF attacks happens in authenticated sessions

We can see that the CSRF attacks happen because of the flaw in the authentication method. To solve this, we use CSRF Token

Ø CSRF Token

CSRF Token is a randomly generated string, which can’t be predicted. For each user session a token will be generated by the server and add it to the form as a hidden field. This will get stored either in cookie or in the session.

On the submission, the server compares the value of the posted field and the value which has been saved in the endpoint of the server.

Now you might have few questions about this CSRF token. Questions like what makes it prevent the attacker from capturing this token and using it to pretend as a legitimate user. And maybe another question like what if the attacker gets the token value, can he perform the attack?

Now let’s discuss about those two questions.

For the first question the answer is, the attacker can’t obtain this token value. Each time when a state changing request happens, a token will be generated. Which makes it impossible to capture this token value.

The second question, think like this by revoking the previous online money transaction scenario.

You loaded the attacker’s website from your browser. So it got open in a different domain other than the attacker’s domain. Since the domains are different, the attacker can’t access the cookie set by the server. Also the attacker can’t execute any javascript, Because the web browser doesn’t allow cross-domain AJAX requests by default (you can enable it by setting CORS Headers).

Ø Mitigating CSRF attacks

As we discussed, we use CSRF token as a solution. But according to the implementation there are few mitigation methods

· Synchronizer token pattern

· Double submit cookie pattern

We can also use methods like new cookie flag.

But in this article, we’ll be focusing on the implementation of Synchronizer token pattern and Double submit cookie pattern.

For this I have used Java as the programing language and the apache tomcat as the server.

Java Server Pages(JSP) is a server side programing technology and Java servlet is a Java software component

For demonstration purposes, I have hardcoded the username and password instead of storing them in a database.

1) Synchronizer token pattern

As the first step create a simple jsp with a login form

Figure 3 – login.jsp

The corresponding page will look something like below

Figure 4 – Login page

When the user provides right credentials and click on Login button, we have to redirect the user to the next page(index.jsp) and upon the successful login we need to create the session identifier and set as a cookie. At the same time, we need to generate a CSRF token. This token value needs to be passed as a hidden field in the file(index.jsp) which includes the form

Let’s dive in to the above code,

Line 21 – User credentials has been validated

Line 25 – I have generated a random string value as CSRF token and stored it in the variable called CSRFToken

Line 27 – Created a new cookie called STPCookie

Line 31 – The cookie has been saved in the browser

Line 33 – A new user session has been started

Line 35 – The token has been saved in the server side endpoint

Line 37 – Redirecting the user to index.jsp, on successful login

Line 40 – If the user credentials are not correct, prompt an error message

Now we need to implement the form which we are redirecting the user, after a successful login.

Figure 6 – index.jsp

In Line 19 I have added a hidden field, which contains the CSRF token value, which generated in the Login.java file.

Still we haven’t done the token validation. We need compare the CSRF token value in the form and the CSRF token value we have stored in the server side endpoint, to check whether they are matching

When user do the submission, we need to check whether it is a HTTP request. and we also have to check whether the form uses POST method in order to make sure endpoint to accept only HTTP POST requests.

Then we should extract the value of the received CSRF token, and need to check whether if it is the correct token issued for the particular session.

Figure 7 – Validate.java

Let’s look at the implementation

Line 20 – Checking whether the request is a HTTP POST request

Line 23 – Extracting the token value which has been received by the server side endpoint. In other words, I have obtained the session cookie and extracted the corresponding CSRF token

Line 24 – Reading the value that I have stored in the hidden field of the index form

Line 25 – Checking whether the session cookie token value match with the received token value

Line 26 – Redirecting the user to the welcome.jsp since the validation was successful

Line 32 – Display error message on invalid CSRF token

Figure 8 – index page

We can make it more secure implementation by using https as the protocol by enabling the secure flag. And also by enabling http only flag in the cookie.

In figure 8, in the circled area you can identify the CSRF Token value which has been passed to the hidden field.

1) Double submit cookie pattern

There is a slight different in the double submit cookie pattern implementation when comparing with the synchronizer token pattern.

Here, we do not save the CSRF Token in the server side. Instead we save it as a separate cookie in the client (Browser).

The generated CSRF Token value will be also saved in the hidden field of the form.

Then upon submission, we compare the CSRF Token value received in the cookie and the CSRF Token value in the message body

When you examine the above code, you can see that I have created two cookies upon successful user login. One is for the session and the other one is for the CSRF token.

In here, I have scanned the available cookies stored in the browser, in order to find the cookie which, I have stored CSRF token value. And also, I have checked whether request is a HTTP POST request.

Line 18 – Retrieving the token value from the HTML form hidden field and storing it in the variable called token

Line 19 – Checking whether the request is a http post request

Line 20 – Check whether the browser has any cookies

Line 21 – Go through each cookie until the end of results

Line 22 – Stores the current cookie in the variable called cookie

Line 23 – Check whether the value of the current cookie is equal to the token

Figure 11 – index page

In figure 11 you can see the token value has been stored in the hidden field of the form

Figure 12 – Token cookie value

In here you can see that the value that has been set in the Token cookie is the same as the value stored in the hidden field of the form.

Search This Blog

Secure Software systems

Cross Site Request Forgery attacks mitigation

Comments

Post a Comment

Popular posts from this blog

A Vulnerability in WhatsApp

Web Application Security

Using OAuth 2.0 Authorization framework

Exploiting Stack Buffer Overflow Vulnerability in EasyChat server

Splunk ES CI/CD pipeline