What is Cross-Site Request Forgery (CSRF)?

Cross-Site Request Forgery (CSRF or XSRF) vulnerabilities are rarely high or critical in their severity ratings. They still can do a lot of harm, however. They’ve been the second most common WordPress vulnerability in recent years after Cross-Site Scripting (XSS) vulnerabilities. You’ll understand how to protect your website better if you know what a CSRF vulnerability is and how attackers commonly exploit them.

Getting Around the Same-Origin Policy

A CSRF vulnerability makes it possible for an attacker to circumvent a standard browser feature called the same-origin policy. All web browsers follow this rule to prevent the kind of interference CSRFs enable. Normally when you’re loading a web page, your browser only interacts with one domain or subdomain, apart from any allowed exceptions. And it will only accept content over one protocol, HTTP or HTTPS (not both), without warning you there’s a problem. If malicious individuals bypass the same-origin policy, they might also trick you into clicking links that perform unwanted actions by unexpectedly interacting with a different site.

In this guide, we’ll dig into the details of cross-site request forgeries. We’ll look at a specific example of a CSRF vulnerability so you understand how they work. Then we’ll show you what you can do to prevent CSRF vulnerabilities from emerging on your site. We’ll also suggest some ways to negate or limit the damage a successful CSRF exploit can do by hardening your site against these and other types of attacks.

Let’s take a look.

How Does a Cross-Site Request Forgery (CSRF) Attack Impact Your WordPress Site?

When a CSRF attack is successful, its victims unintentionally authorize a harmful action, like an update to their login credentials. They might be tricked into allowing an attacker to take over their user account. Worse, a victim of a CSRF exploit might let attackers initiate financial transfers on their behalf.

If a plugin on your WordPress site contains a CSRF vulnerability, an attacker might be able to hijack some user accounts. That would be one of the worst-case scenarios. If a stolen account has an administrative role in WordPress or the user reuses their password on other sites, the damage could be extensive.

How Does a CSRF Attack Work?

Three different conditions must exist for a hacker to make a CSRF attack work. If you understand them on a general level, you’ll have a good working grasp of some web security fundamentals.

1. Cookie-Based Session Handling

Like other stateless applications, WordPress relies on session cookies to identify users. Under low or compromised security conditions, an attacker might be able to bake up some fake session cookies or manipulate a logged-in user to take some unwanted action. WordPress will accept forged and manipulated requests that are or appear to be from a logged-in user.

While CSRF exploits often target cookie-based session handling, that’s not their only target. CSRF attacks can be effective against any application that automatically adds user credentials to requests. Certificate-based authentication and HTTP Basic authentication are also susceptible to CSRF vulnerabilities for this reason.

2. A Relevant Action Can Be Targeted

There must be some action within the targeted application that victims can be tricked into taking. This could be a privileged action like changing user permissions. It could be related to user-specific data, like updating a user’s password. These are common actions in all web applications, including WordPress. They have value as targets for hackers because they might open a path for them to steal user accounts and dig deeper for ways to engage in theft, fraud, or other malicious activity.

3. No Unpredictable Request Parameters

The requests that perform the targeted action must be known or predictable. If the targeted requests don’t need to contain parameters whose values the attacker cannot determine or guess, they’re more vulnerable to manipulation.

For example, if a valid password change request must include the existing password, it’s secure — as long as an attacker doesn’t know the password. CSRF tokens and SameSite cookies add further obstacles to attackers when developers use them to secure their code. But sometimes developers don’t implement these security methods correctly or at all. (This is why strong, passwordless user authentication is valuable.)

Exploiting a CSRF Vulnerability to Change User Account Emails — An Example

Here’s a more in-depth example. It won’t actually work, but it illustrates the main concepts in play for an effective CSRF exploit.

Consider an email change request. When a user performs this action, they make an HTTP request that looks something like this to the web server receiving it:

POST /test HTTP/1.1
Host: yourwebsite.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 60
Cookie: session=yvthgjrudhgeQkAPzeQ5gHgTvlyxHfsAfE;[email protected]

Why It Works

This meets the conditions required for CSRF if/because:

• The targetted site/application uses a session cookie to identify which user issued the request, and there are no other tokens or mechanisms in place to track user sessions. This is why developers should use CSRF tokens and/or SameSite cookies.
• Changing a user’s email address is a relevant action in the interest of an attacker. It sure is! If you can change a user’s email address to one you control, you can take complete control of their account.
• The attacker knows the request parameters they need to change a user’s email address and can generate valid values for them. These parameters are not secret, and it is not difficult to determine what email addresses many people use for their online accounts. The session cookie is trickier.

How an Attacker Might Steal Session Cookies

The attacker’s main hurdle is determining the actual values for the parameters that will access a particular user’s account. They might do that by building a web page aimed at users of the targeted site. This deceptive site might have links or buttons that appear to have a legitimate purpose, like requesting free gifts. In reality, if you click those links or buttons, the only person getting some sweet goodies for free is the attacker.

When you click these fraudulent links, they will make a change-address request to the targeted and CSRF-vulnerable site. If you’re logged into that site, the request will be valid. Your account has been stolen — you handed over your keys.

Users of a WordPress site who remain logged into it have an active session cookie in their browser that persists even when they’re on a different site. Their browser will automatically include that session cookie within a forged request. WordPress may see this as a perfectly valid change-address request — even though it’s coming from another site and the user has no idea they’re making it.

Assuming no other security measures are in place, like the SameSite cookie attribute, the vulnerable target site will process a forged request the same as a valid one. If the targetted website doesn’t enforce an address change confirmation step, or if the attacker has a way around it, the attacker will successfully change the user’s address to any the attacker chooses.

How a CSRF Attack Is Delivered To a Vulnerable Website

The delivery mechanisms for CSRF attacks and Reflected Cross-Site Scripting (Reflected XSS) attacks are similar.

In most cases, attackers will place their malicious code on a deceptive site they control. This could be a legitimate site they’ve already compromised, which is why Google maintains a deceptive site list. All browsers will warn their users away if you’re on this list! This is why iThemes Security checks every day to make sure your site hasn’t become a hacker’s tool.

Getting potential victims to visit a deceptive website is simply a matter of basic social media and email marketing. Sometimes the malicious code is simply placed on a popular site in an active area.

An attacker may not even need a website to lure their victims. Some simple CSRF exploits use the GET method. This is what your browser does when you click a link or enter a URL in the address bar. It makes a GET request using the URL in the link or that you provide. Sometimes a CSRF attack can be fully executed with a single GET request to a vulnerable website. In situations like this, the attacker might not need to use a deceptive website. They can simply feed their victims a malicious URL directly.

Protecting Your Site from Cross-Site Request Forgery (CSRF) Attacks

CSRF vulnerabilities frequently surface in plugins and sometimes themes. When hackers target them, it’s not hard to protect yourself. Use quality plugins and themes you trust, remove the ones you’re not using, and keep all your software up to date. You should also implement a well-considered user security policy and consider going passwordless. If a CSRF vulnerability (or any other) is exploited on your site to gain access to user accounts, it won’t do much good to the attacker if you’re using passkeys. Nobody can steal what doesn’t exist.

In addition to managing updates and warning you about vulnerable plugins and themes, iThemes Security Pro makes it easy to set up and manage user and role-based security rules. Delegate privileges based on the principle of the least privilege. Secure your login, password recovery, and contact forms with CAPTCHAs. Don’t give your users greater capabilities than they need. Require higher privilege users to use stronger authentication methods. And definitely adopt the most convenient, drop-dead simple way to log into WordPress without a password: Passkeys!