What is CSRF?

CSRF (Cross-Site Request Forgery) is a type of attack which tricks the victim to do a task on the victim authenticated web-application on behalf of the interests of the attacker. An application vulnerable to CSRF enables attackers to perform any actions on the victim’s behalf without his/her knowledge.  

Assume currently you are shopping on a website that uses inhouse credits as currency. You are currently logged into the site and browsing for some products. Then you visit some other site for cool new wallpaper for your desktop, not knowing that it is a malicious site and you hit the download button for the image.

Now, if the owner of the site knows that the shopping website is vulnerable to CSRF -> He will include a request on his page to the shopping website that requests products on the given attacker’s address. As you are already logged into the shopping website - It will be you, who is requesting the products on the attacker’s address(victim’s IP and cookies). Shopping websites using the inhouse credits will deduct the credits from your account - without your knowledge. 

Using CSRF tokens and cookies

Preventing CSRF attacks

The good news is that a CSRF attack can easily be prevented by using a CSRF token. This security practice makes use of a dynamic unpredictable token associated with every logged-in user, that keeps changing with every request. This token can be found as a hidden value in the webpage of the current browser session and is sent along with every request made by the user - Ensuring that only the actions performed on the legit page can access this token. Let’s take a look at a secure implementation of CSRF tokens in a form-based web-application.

1. The logged-in client requests an HTML page that contains a form.
2. The server includes two tokens in the response. One token is sent as a cookie to authenticate the user(Cookie or XSRF-token). The other in the hidden form field.
3. When the client submits the form, both the tokens must be validated on the server-side before processing the request.

The sequence of authentication of actions on the server-side must be as follows:

1. The user ID should be derived from the received cookies and token from the Header information of the request.
2. Token from the Post data/form should be validated for - it belongs to the same user confirmed in step 1.
3. Process the received form for the authenticated user. 

Implementing CSRF Protection in Joomla

Joomla natively provides functions to implement protection against CSRF attacks. Implementation of this protection mechanism is also quite easy and simple - as functions to generate unpredictable random tokens and functions to verify them as per users’ sessions are already provided by Joomla. Let’s see how we can implement them to secure our application.

Anti - CSRF tokens in Joomla are sent using forms in POST requests. The following code must be included on the page to create this token.

<?php echo JHtml::_( 'form.token' ); ?> 

This will generate and set a random token for the currently logged-in user session. The output of the above function will be similar to this.

<input type="hidden" name="0987654321abcdef0987654321abcdef" value="1" />

Now we also have to write code to verify this generated token. This code must be written on the page that processes the request generated in the previous page. 

// Check for request forgeries

$this->checkToken();

This check for validity of the token must be written such that - the check for the token is processed before processing the actual request. This can be implemented by using the function as follows.

JSession::checkToken() or die( 'Invalid Token' );

Where to not use CSRF tokens?

Sometimes, If we are using some functionality from 3rd parties, the CSRF tokens must not be used - as the 3rd party will not know what CSRF token to send to your web-application. For example, if you are using Stripe to process payments and are utilizing their webhook system, you will need to exclude your Stripe webhook handler route from CSRF protection. 

It should be noted that the script / HTML request from the attacker’s site normally does not have access to your XSRF or Cookie token because of the HTTP access control. This note is particularly important for people unreasonably sending header Access-Control-Allow-Origin: * for every website response without knowing what it is for, mainly to get their API from another website working.

Protection against CSRF for Users

From a user’s perspective, prevention is a matter of safeguarding login credentials and denying unauthorized access to applications.

Best practices include:

1. Logging off-web applications when not in use.
2. Not using the “Remember Me” option on the login pages.
3. Not allowing browsers to remember passwords.
4. Avoid simultaneously browsing while logged into a sensitive application.