Web vulnerabilities are rampant and constantly increasing. Maintaining the security and privacy of your users is more important than ever. Not addressing web vulnerabilities can lead to a ruined reputation and hefty fines from regulators, and you’ll also lose your users’ trust.
Websites and web applications are vulnerable to malware, spam, and other attacks — this article focuses on one such attack vector — Cross-Site Request Forgery (CSRF) attacks. CSRF attacks are particularly troubling because they can occur without the user’s knowledge. They’re also difficult for a developer or website owner to detect because the malicious requests appear highly similar to genuine requests.
This article explores a CSRF attack, how it works, and the steps you can take to prepare for one.
Check Out Our Video Guide To Understand All About CSRF Attacks
What Is a CSRF Attack?
A Cross-Site Request Forgery attack, also known as a CSRF attack, tricks an authenticated user into performing unintended actions by submitting malicious requests without them realizing it.
Typically, a CSRF attack involves state-changing requests because the attacker doesn’t receive a response. Examples of such requests include deleting a record, changing a password, purchasing a product, or sending a message. These can all occur without the user’s knowledge.
The malicious attacker typically uses social engineering to send an unsuspecting user a link through chat or email.
When the user clicks the link, it executes the commands the attacker sets.
For instance, clicking on a link can transfer funds from a user’s account. Or, it can change a user’s email address preventing them from regaining account access.
How Does a CSRF Attack Work?
Getting the user to initiate a state-changing request while logged in is the first and most crucial step in a CSRF attack. With CSRF attacks, the attacker aims to get an authenticated user to unknowingly submit a malicious web request to a website or web application. These requests can consist of cookies, URL parameters, and other data types that appear normal to the user.
For a CSRF attack to be successful, the following conditions must occur:
- An authenticated user must be logged into a web application that uses cookies for session management.
- An attacker must create a state-changing forged request.
- Genuine requests handled by the target server should not contain unpredictable parameters. For instance, the request should not expect a password as a parameter for verification purposes before initiating the state-changing request.
The most common method of completing CSRF attacks is using cookies in applications with a weak SameSite cookie policy. Web browsers include cookies automatically and often anonymously, and they save cookies used by a domain in any web request a user sends to that domain.
SameSite cookie policy defines how the browser in cross-site browsing contexts treats the cookie. If set to strict, the cookie isn’t shared in cross-site browsing contexts, preventing CSRF attacks. The browser attaches the cookie in all cross-site contexts if it’s set to none. This leaves the application vulnerable to CSRF attacks.
When a user unknowingly submits a malicious request through a web browser, the saved cookies cause the request to appear legitimate to the server. The server then responds to the request by changing the user’s account, changing the session state, or returning the requested data.
Let’s take a closer look at two examples of CSRF attack avenues, one with a GET request and the other with a POST request.
CSRF for a GET Request
First, consider a GET request used by a financial banking web application, where the attack exploits a GET request and hyperlink delivery.
Suppose the GET request for transferring money looks something like this:
GET https://xymbank.com/online/transfer?amount=1000&accountNumber=547895 HTTP/1.1In the genuine request above, the user requests to transfer $1,000 to an account with 547895 as payment for purchased products.
While this request is explicit, simple, and practical, it exposes the account holder to a CSRF attack. That’s because the request doesn’t require details an attacker may not know. So, to initiate an attack, an attacker would only need to alter this request’s parameters (the amount and the account number) to create an executable forged request.
The malicious request would be effective on any of the bank’s users as long as they have ongoing cookie-managed sessions.
Here’s how the forged request to transfer $500 to a hacker’s account (here, number 654585) would look. Note that the example below is a highly simplified version of the steps involved in a CSRF attack for an explanation.
GET https://xymbank.com/online/transfer?amount=500&accountNumber=654585 HTTP/1.1Once that’s complete, the attacker must figure out a way of tricking the user into sending this request while logged into their online banking application. One of the ways to do this is to create a harmless hyperlink that gets the user’s attention. The link may look like this:
<a
href="https://xymbank.com/online/transfer?amount=500&accountNumber=654585">Click here to get more information</a>.Given that the attacker has found the correct email addresses of their targets, they can send this through email to many bank customers. Those who click the link while logged in would trigger the request to send the attacker $500 from the logged account.
CSRF for a POST Request
Let’s see how the same financial institution would experience a CSRF if they only accepted POST requests. In this case, the hyperlink delivery used in the GET request example wouldn’t work. Therefore, a successful CSRF attack would require an attacker to create an HTML form. The genuine request to send $1,000 for a product purchased would look like this:
POST /online/transfer HTTP/1.1
Host: xymbank.com
Content-Type: application/x-www-form-urlencoded
Cookie: session=FRyhityeQkAPzeQ5gHgTvlyxHJYhg
amount=1000
account=547895This POST request requires a cookie to determine the user’s identity, the amount they wish to send, and the account they want to send. Attackers can alter this request to perform a CSRF attack.
The attacker must only add a genuine cookie to a forged request to make the server process the transfer. They can do that by creating a harmless-looking hyperlink that takes the user to a trigger web page that looks like this:
<html>
<body>
<form action="https://xymbank.com/online/transfer" method="POST">
<input type="hidden" name="amount" value="500"/>
<input type="hidden" name="account" value="654585" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>We’ve already set the amount and account parameters in the form above. Once an authenticated user visits the page, the browser adds the session cookie before forwarding the request to the server. The server then forwards $500 to the hacker’s account.
3 Ways To Abate CSRF Attacks
There are several methods to prevent and drastically mitigate potential CSRF attacks on your website or web application, including:
- Using CSRF tokens
- Using the referrer header
- Choosing a security-focused hosting solution, like Kinsta
How To Prevent CSRF Attacks Using CSRF Tokens
A CSRF-secure website assigns each session a unique token and shares it with the server side and the client browser. Whenever a browser sends a sensitive request, the server expects it to contain the assigned CSRF token. If it has the wrong token, the server drops it. The CSRF token isn’t stored in session cookies on the client’s browser for security purposes.
Potential Vulnerabilities of CSRF Tokens
Although CSRF tokens are an excellent security measure, this method isn’t attack-proof. Some of the vulnerabilities accompanying CSRF tokens include:
- Validation bypass — Some applications skip the verification step if they don’t find a token. If an attacker gains access to code that contains a token, they can remove that token and successfully execute a CSRF attack. So, if a valid request to a server looks like this:
POST /change_password
POST body:
password=pass123&csrf_token=93j9d8eckke20d433An attacker needs only to remove the token and send it like this to execute the attack:
POST /change_password
POST body:
password=pass123- Pooled tokens — Some applications maintain a pool of tokens to validate user sessions instead of designating a specific token to a session. An attacker only needs to obtain one of the tokens already in the pool to impersonate any of the site’s users.
An attacker can log in to an application using their account to obtain a token, such as:
[application_url].com?csrf_token=93j9d8eckke20d433And since the tokens are pooled, the attacker can copy and use that same token to log in to a different users account, as you will use it again:
- CSRFs can be token copied to the cookie — Some applications will copy the parameters related to a token into a user’s cookie. If an attacker gains access to such a cookie, they can easily create another cookie, place it in a browser, and execute a CSRF attack.
So an attacker can log in to an application using their account and open the cookie file to see the following:
Csrf_token:93j9d8eckke20d433They can then use this information to create another cookie to complete the attack
- Invalid tokens — Some applications don’t match CSRF tokens to a user session. In such cases, an attacker can genuinely login into a session, obtain a CSRF token similar to those above, and use it to orchestrate a CSRF attack on a victim’s session.
How To Prevent CSRF Attacks with the Referrer Header
Another strategy for preventing CSRF attacks is using the referrer header. In HTTP, referrer headers indicate the requests’ origin. They’re typically used to perform analytics, optimization, and logging.
You can also enable checking referrer headers on the server side to prevent CSRF attacks. The server side checks the source origin of the request and determines the target origin of the request. If they match, then the request is allowed. If there’s a mismatch, the server drops the request.
Using referrer headers is much easier than using tokens because it doesn’t require individual user identification.
Potential Vulnerabilities of the Referrer Header
Like CSRF tokens, referrer headers have some significant vulnerabilities.
First, referrer headers aren’t mandatory, and some sites will send requests without them. If the CSRF doesn’t have the policy to handle requests without headers, attackers can use headerless requests to execute state-changing attacks.
Additionally, this method has become less effective with the recent introduction of the referrer policy. This specification prevents URL leakage to other domains, giving users more control over the information in the referrer header. They can choose to expose part of the referrer header information or to disable it by adding a metadata tag on the HTML page, as shown below:
<meta name="referrer" content="no-referrer">The above code removes the referrer header for all requests from this page. Doing so makes it difficult for applications that rely on referrer headers to prevent CSRF attacks from such a page.
How Kinsta Protects Against CSRF Attacks
In addition to using the referrer header and CSRF tokens, there’s a third and way easier option: choosing a secure hosting service like Kinsta for your websites and web applications provides a much stronger and more secure barrier between attackers and your users.
On top of critical security features such as automatic backups, two-factor authentication, and SFTP over SSH protocols, Kinsta’s Cloudflare integration provides enterprise-level protection with IP-based and firewall protection.
Specifically, Kinsta currently has around 60 custom firewall rules to help prevent malicious attacks and deal with severe unauthenticated vulnerabilities in plugins and themes, including specific ones that look for CSRF vulnerabilities.
Summary
Cross-site request forgery (CSRF) is an attack that tricks authenticated users into initiating state-changing requests unintentionally. They target applications that can’t differentiate between valid and forged state-changing requests.
CSRF can only be successful on applications that rely on session cookies to identify logged users and have a weak SameSite cookie policy. They also need a server that accepts requests not containing unknown parameters such as passwords. Hackers can send malicious attacks using either GET or POST.
Although using CSRF tokens or enforcing referrer header verification can prevent some CSRF attacks, both measures have potential vulnerabilities that can render your preventive measures useless if you’re not careful.
Migrating to a secure hosting platform like Kinsta secures your websites or web apps from CSRF attacks. Furthermore, Kinsta’s integration with Cloudflare prevents specific CSRF attacks.
Leave a Reply