WordPress CSRF attacks: what they are and how to prevent them?

WordPress CSRF (cross-site request forgery) attacks are one of the most common security vulnerabilities plugin, theme, and website developers have to account for. A dedicated hacker can take over admin accounts (and, by extension, your website), get users to reveal personal information or delete their accounts, and even steal money from them with a well-executed CSRF attack.

This article explores CSRF attacks, how they work, and what you can do to prevent them.

What is cross-site request forgery (CSRF)?

Cross-site request forgery (CSRF, pronounced “sea-surf”) is, in simple terms, when hackers trick users into performing an unwanted and malicious action while logged into a trusted site. That is, they exploit membership, subscription, form, and login mechanisms to leverage the user’s trust and get them to reveal authentication credentials, give up funds from their bank accounts, and potentially do many other harmful actions for the user and the website they trust.

Along with cross-site scripting (XSS), SQL injection attacks, and bypasses, CSRF attacks are among the most common and persistent threats to WordPress sites and the internet.

How do CSRF attacks happen on WordPress sites?

The inner workings of CSRF require an explanation since they can be hard to grasp at first. To understand it, imagine an example in which a hacker tricks a user into deleting their web forum account.

An unsecured website

The forum vulnerableforum.com is a regular forum where users can discuss various subjects. It’s a very basic and not very secure website that allows users to log in and out, change their passwords, make some changes to their profiles, and delete their accounts.

If you want to delete your account, the forum sends you to the page vulnerableforum.com/delete_my_account. In this page, you’ll have to confirm your choice by clicking on a button that reads, “Yes, I want to delete my account.” Pressing it permanently deletes your account.

A hacker can trick you into pressing this button without you even being on the page by using CSRF. Here’s how.

Tricking you into deleting your account

A user is browsing through vulnerableforum.com. They are logged in and find a forum thread with a link to koalas.com where they can see pictures of cute koalas. Naturally, the user clicks on the link thinking it’ll lead them to a site with many images of cute koalas. In reality, the user is doing two things:

• Visiting a website with pictures of koalas.
• Unwittingly deleting their own account on vulnerableforum.com.

How did the hacker do this? What they did was sneakily get you to press the “Yes, I want to delete my account” by hiding a specific HTTP POST request to the server that hosts vulnerableforum.com. More specifically, a POST request to /delete_my_account.

And because this happened in the context of an authenticated user, the server assumes that the user actually wants to delete their account and follows through with the request.

Exploiting cookies

Web cookies are small text files web servers create when you connect to them, like when visiting vulnerableforum.com. Cookies identify your device with information like passwords, usernames, login information (so you don’t have to log in every time), your shopping cart, etc.

Users and web servers automatically exchange cookies every time the user makes an HTTP request, and the server sends a response. Crucially, the exchange occurs regardless of your current web domain. Hackers can hide a “delete my account” request to the vulnerableforum.com server in an innocent-looking link to an unrelated website like koalas.com.

If web servers don’t check where requests come from, anyone from any domain can get users to perform any action on a server. And because that user sent their unique cookies along with the request, the server will assume it’s a legitimate request instead of a malicious one.

Just like the hacker in this example got a user to delete their account, they could easily get them to change their passwords so only the hacker knows it, transfer money from their bank account, and more.

What does “CSRF” mean?

We can understand where the name comes from now that we know how CSRF attacks work.

• The “cross-site” part comes from the fact that multiple domains are exchanging information. In this example, it was koalas.com and vulnerableforum.com.
• The “request” part comes from the user making a request to the web server. In this example, the hacker tricked the user into requesting the vulnerableforum.com server to delete their account.
• Finally, the “forgery” comes from the fact that the hacker forged or fabricated a fraudulent request to harm a user, a website, or both. In this example, the hacker forged a POST request to vulnerableforum.com, which the server accepted because it didn’t check the origin (koalas.com).

Why do WordPress sites suffer CSRF vulnerabilities?

The most common reason WordPress sites suffer from CSRF attacks (and security breaches in general) is vulnerable plugins. Sometimes, plugins are coded in a way that allows these tactics to go unnoticed due to developer oversights or advanced hacker tactics.

Plugin developers can take two very effective and widely accepted security measures to minimize CSRF attacks: anti-CSRF tokens and nonces.

• Anti-CSRF tokens. These are character strings generated randomly by the server and assigned to each user session. The server only accepts user requests if the token and correct are present along with the cookies. Since hackers cannot access it, all their forged requests will be rejected.
• One-time tokens. One-time tokens, one-time keys, or “nonces” are similar to anti-CSRF tokens but have a time limit. Often, they’re valid for no more than a few minutes. Nonces are dynamically created when users fill out forms (like when logging in), and hackers don’t have access to them either.

How to prevent or stop CSRF attacks in WordPress?

From a website owner standpoint, this is what you can do to protect yourself and your users from CSRF attacks.

Protect custom forms with nonces

Web forms or HTML forms are web elements where users can input data that the server processes. They allow users to enter authentication credentials, sign up for newsletters, make online purchases, and more.

Forms without CSRF protection are vulnerable and a very common vector for hackers to exploit. When deploying custom forms, adding a nonce and verifying it every time a POST request is processed is recommended. The following code adds a nonce to your form:

<form id="test-form" method="POST">
    <input name="form_nonce" type="hidden" value="<?php echo wp_create_nonce('test-nonce')?>" />

And this checks the nonce upon every POST request:

if (isset($_POST['form_nonce']) && wp_verify_nonce($_POST['form_nonce'],'test-nonce') && isset($_POST['new_email']) && is_user_logged_in()) {

With these two snippets, you’ve protected your website from most forms of CSRF.

Delete unused plugins and themes

Considering plugins are the most common source of CSRF vulnerabilities, having more third-party software interacting with your site opens up more avenues for hackers to attack you. That’s an inevitable reality of owning a website, WordPress or otherwise. 

Delete any plugins and themes you’re not currently using to minimize entry points. Themes are not often the source of vulnerabilities, but they can be, and it’s best to avoid the ones you’re not using.

Log out users automatically

CSRF attacks can only work when the user is logged in. By automatically logging out users who’ve been inactive for a certain period, you can deny hackers access to their accounts for the purposes of CSRF.

This is one of the reasons online banks and other websites that manage very sensitive information log out users so aggressively, sometimes only after a couple of minutes of inactivity. While not a definitive solution, it’s another obstacle to hackers.

Stay safe from WordPress CSRF attacks

CSRF attacks are a very old internet security threat that still gives trouble to modern websites. Given its popularity, WordPress is often the target of hackers trying to steal credentials and money or simply cause trouble with CSRF attacks.

Thankfully, there are security measures you can take to minimize the chances of hackers manipulating your users into taking unwanted actions. With the information we’ve provided, you’re better positioned to protect yourself and your users from these kinds of attacks.

If you found this article helpful, consider reading our blog for more WordPress guides, tips, and insights.