Cross-Site Request Forgery (CSRF)

What is CSRF

CSRF, also known as XSRF, Sea Surf or Session Riding, is a common attack that tricks a web browser into executing an unwanted action in an application to which a user is logged in. Normally this is done by inducing the user by allowing him to click a link which includes the malicious request that the attacker want to perform. The reason to consider CSRF as highly dangerous is, just by one click something that user never want to happen can be performed.

Examples for CSRF

A very common example for CSRF attack is, stealing money from the users who perform online transactions. But keep in mind that there are many other things that thieves or in this case hackers steel from users.

Impact of a successful CSRF attack

Well a successfully performed CSRF can do a big impact on both user and the organization.

· Damaged client relationships

· Data theft

· Changed credentials & restricted access to user

· Unauthorized fund transactions

How CSRF is performed

in most of the cases CSRF attacks were performed using malicious social engineering. It may be an email, link or any other thing which gets the uses attention such as an offer or give away sort of thing. Clicking the email or the link will allow the malicious URL to execute and perform its task.

Normally before performing an CSRF attack, the attacker exploits how the target web application deals with authentication. In order to perform the CSRF successfully the victim must be authenticated in the targeted site. Typically, attackers study the application behavior and tries to make the forged request to look as legitimate as possible.

CSRF attack prevention

In order to prevent from CSRF attack, some assumptions must be verified:

· the attacked website does not check the Referrer HTTP header, so that it accepts requests originating from external pages.

· The website accepts data modification via form submissions or URLs that have side effects which the attacker can exploit.

· The attacker can determine all the values for the request inputs. In the simplest case, authentication is done exclusively via a session cookie and so the attacker just has to fill non-sensitive fields.

· The user must load a malicious page containing the attacker’s code.

There are two major security patterns that can use to prevent a CSRF attack.

1. Synchronizer Token Pattern

2. Double Submit Cookie Pattern

Let’s look at both patterns individually.

Synchronizer Token Pattern

Introduction

Synchronizer token pattern is a technique where a token, secret and unique value for each request, is embedded by the web application in all HTML forms and verified on the server side.

Let’s look at the actual code to get an idea how it works..

Here login form submits credentials of user using a POST method. If the user is allowed, a unique Session ID and the CSRF token is created along with the newly started session and at the same time generated session ID set as a cookie in the browser. CSRF token is stored against the session identifier at the server side. you can see the stored CSRF token in the token.txt file.

After successful login attempt, the browser will send an Ajax request to get the CSRF token from csrf_token_generator.php. This Ajax request contains the session ID. Then the server will response the request by providing corresponding CSRF token along with the response body. Here the CSRF token generator creates a 32bit long CSRF token. The generated token value is encoded using base64 encoder to ensure security.

When the user clicks “update post” button the POST is sent. The server validates session id which came with the request header and CSRF token in the body.

Pros & cons

The biggest advantage of using this pattern is, it is simple and works with AJAX, forms etc. But all forms must reveal the hidden field in HTML and any AJAX request should contain the value. In practical environment such as a large e-commerce site it will be time consuming when number of pages which requires token value is high.

Double Submit Cookie Pattern

Introduction

Storing a CSRF token in session might be an issue when the number of users who uses the site is high. Therefore, double submit cookie pattern is used as an alternative method. What happens in double submit cookie pattern is it sends a random value in both cookie(header) and in request parameter. The server verifies the request if the cookie value and request values match with each other.

When user enters to a site, that website generates a session id and set a session cookie in the browser. Also, it generates a CSRF token for session and sets it as a cookie in the user’s browser. The user needs to have this random value as a hidden value (or another request parameter). Attacker can not read data sent from the server or modify cookie values according to the same origin policy.

Here the login form submits user credentials using POST method. If the user is allowed successfully(authenticated), server will create a unique Session ID and the CSRF token. But the server only stores the Session ID.

Then the server will response to the corresponding CSRF token along with the response body. After that, generated session id & server respond CSRF token is stored as cookies in the browser. In here we must set the HTTP only flag “false” because JavaScript should able to access the CSRF token cookie to add to the hidden field in the post request.

Then user will be redirect to user status update page. In this page, there is an AJAX call to get the stored CSRF token from the browser cookies. Then the corresponding CSRF token added to the hidden field.

Here we a field to update user status. When user updates it, it goes as a POST request. The post request contains this generated CSRF token and the session cookie. When the user clicks “updatepost” button, the Post request is sent. Then the server validates the cookie header for session id and server compares CSRF token from request body (hidden field value) against CSRF token from the header cookie. If these tokens are matched with each other than server accepts the request.

Conclusion

Both patterns can be implemented in real world web sites to prevent from CSRF attacks.