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.
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.
The sequence of authentication of actions on the server-side must be as follows:
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 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' );
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.
From a user’s perspective, prevention is a matter of safeguarding login credentials and denying unauthorized access to applications.
Best practices include:
When you subscribe to the blog, we will send you an e-mail when there are new updates on the site so you wouldn't miss them.