Cross-Site Request Forgery (CSRF) attacks WordPress are among the oldest attacks of all.

Cookies as a Threat: Cross-Site Request Forgery

CSRF, this abbreviation appears again and again in the security and maintenance updates of the WordPress core. The method behind it is now old hat and exploits the abundant cookies of an Internet user. Fortunately, however, you can protect yourself from cross-site request forgery quite easily. All you need is a little time and attention.

You probably also use a number of services that offer the option to stay logged in even after you leave site . If you then visit site again, you do not have to enter your login data again, but are logged in directly. For the user, this is of course great, because it - just like a password management or a so-called Single Sign On - saves annoying form filling.

The following happens in the background: When you log in to site for the first time, the website stores a cookie in your browser. This is a small text file in which certain information can be stored. In the case of staying logged in, this is a randomly generated character string.

The next time you visit the website, the server checks this character string and, if it can find the corresponding counterpart, logs you in automatically. This is also the reason why you are logged out everywhere when you clear your browser cache. Because all cookies are also deleted during this process.

A CSRF attack is, at its core, an abuse of trust.

As you can see, in a corresponding attack, the attacker tricks the service that reads the cookies into believing something. How exactly this happens, I explain below with two examples.

The danger of this manipulation lies in the fact that a third party, i.e. the attacker, makes changes to your Facebook profile in your name, for example. However, cross-site request forgery is often also dependent on phishing. Here, too, trust becomes relevant - namely your trust in, for example, the senders of e-mails.

Cross Site Request Forgery (CSRF) attacks on WordPress can be prevented by common sense.

How vulnerable is WordPress ?

You probably haven't heard the term Cross-Site Request Forgery as often as Brute Force attacks or cross-site scripting. There's a reason for that: the non-profit organization OWASP (Open Web Application Security Project) regularly publishes a list of the ten most critical vulnerabilities in web applications. On the preliminary list for 2017 CSRF occupies 8th place out of 10. In 2007 and 2010, the attack still landed at 5th place, In 2013, it dropped to number eight descended.

This is probably due in part to the fact that CSRF attacks are almost as old as the Internet itself. Professional developers are now well practiced in securing their code against them. So security risks are quite easy and quick to fix.

WordPress is also on the lookout. For example, security update 4.7.5 was released in May, which fixed six vulnerabilities that hackers could have used to launch an attack via cross-site scripting or cross-site request forgery. Often cross-site scripting is often considered to be much more dangerous.

Moreover, the issue of cross-site request forgery tends to be more relevant for Plugin- and application developers than for web designers, agencies and SMEs. This is because protection against CSRF is also a question of programming. CSRF could become relevant, for example, in the case of in-Plugin purchases.

But how does the whole thing work now?

The Anatomy of Cross-Site Request Forgery

The basic idea behind a CSRF attack is relatively simple and usually happens in two steps:

  1. The hacker tricks the victim into loading a manipulated site or clicking on a link, for example by pretending to be a trusted person or exploiting human curiosity. In other words, phishing plays an important role in this type of attack.
  2. When loading or clicking on the manipulated links or sites , the victim's browser executes an HTTP request without the victim noticing.

Two relatively simple examples illustrate how such an attack works.

For this, let's assume that Justus wants to tell Bob about the site 100€, and Skinny is sitting in wait to perform a CSRF attack. Skinny can now use, for example, the GET or POST method for his attack.

By the way, the following examples are from the following sources:

Cross-Site Request Forgery with the GET Method

The GET method is used to request a resource from a server, for example an HTML file. The required parameters for the call are simply appended to the URL. And as we already know from SQL injections: A URL is relatively easy to manipulate.

So Justus logs in at and enters all necessary data. The following (completely fictitious) input would be transmitted to the server:


Skinny now constructs a URL that transfers €100,000 to his own account instead. It looks like this:

Of course, Justus has to perform the action hidden behind the fake link. Therefore, Skinny sends Justus a mail with a fake link. The HTML code can look like this, for example:

<a href="">Wer dieses Rätsel nicht lösen kann, ist kein echter Detektiv!</a>

Or he sends him an email that contains an "invisible" (because 0 by 0 pixels) image. When trying to load the image, the browser accesses the URL without Justus even noticing:

<img src="" width="0" height="0" border="0">

When Justus calls up the link - consciously or unconsciously - the parameters are transferred to the server, the transfer is initiated and €100,000 disappears from his account.

Of course, Justus has to click on the link while logged in. But if, unfortunately, his browser contains a login cookie from his bank the attack works even if he has not opened site .

This is exactly what makes cross-site request forgery so insidious: the victim may not even be aware that the cookie exists.

Cross-Site Request Forgery with the POST Method

The GET method can be used in links and is thus particularly easy to spread. This naturally plays into the hands of the attacker in terms of distribution. Now, however, providers can ensure that GET requests do not receive write permission in principle.

The POST method remains: Here, data is transferred to a server so that it can process it further. The data is not part of the URL, but is appended to the header.

Might sound a bit bulky, but you certainly know the use case. Because forms work this way.

For our attacker, Skinny, that means he has to put in more effort, but he can still get where he's going.

Same scenario: Justus wants to transfer money to Bob. So he fills up and fills out the following form:

<form method="POST" action="geld_ueberweisen.php">

    <input type="text" name="von">

    <input type="text" name="an">

    <input type="text" name="betrag_in_euro">

    <input type="submit">


This sends the money_transfer.php command, which looks like this:

if(isset($_FORM["von"]) && isset($_FORM["an"]) &&isset($_FORM["menge_in_euro"]) && isset($_CMOKIE["user_eingeloggt"]))


    transMoney("von", "an", "betrag");

    echo "Überweisung erfolgreich!";


As you can see, the code first checks whether Justus is logged in using the cookie. Only if he is, the transfer will be executed.

Skinny now deposits an invisible form on a manipulated web page, e.g.

<form method="POST" action="">

    <input type="text" name="von" value="Justus" style="display: hidden">

    <input type="text" name="an" value="Skinny" style="display: hidden">

    <input type="text" name="betrag_in_euro" value="100000" style="display: hidden">

    <input type="submit" value="Wer dieses Rätsel nicht lösen kann, ist kein echter Detektiv!">


He sends the link to this manipulated website to Justus. Feeling challenged, he clicks on the button to see the puzzle; and he unknowingly executes the function geld_ueberweisung.php. Since this one finds a corresponding cookie in his browser, €100,000 are transferred to Skinny again.

Attack via detours

That's why the name CrossSite Request Forgery: The hacker usually sends the command from another site . To attack site A, he deposits malicious code at site B. He then lures the unsuspecting user here so that his browser executes the code. Then he lures the unsuspecting user here so that his browser executes the code.

How dangerous are Cross Site Request Forgery (CSRF) attacks at WordPress ?

How to secure yourself against CSRF attacks

The good news is that cross-site request forgery has been around for ages. Developers know the risk and are working specifically to eliminate it.

The bad news: You can't really protect yourself against it on a technical site level. The WordPress Core is now relatively well protected, and as you can see from the ongoing updates, it is constantly being worked on. As with other types of attacks, most vulnerabilities come along with plugins it. So you have to trust that the developers of the extensions you use are doing a good job.

That means specifically:

  • Don't install too many plugins and only install the plugins you really need.
  • Watch out for plugins those that have not been updated by the developers for a long time. This could be the hiding place of unfixed security holes.
  • Inform yourself in advance about the plugins that you install, for example about their compatibility with other plugins or the WordPress version you are using (so that it plugins can be updated).
  • Update your plugins and the WP core regularly. Because the continuous updates are exactly there to close such security holes.
  • You critical in terms of phishing
  • If you're unsure, take a close look at Plugin in the WP repository. What are the ratings, what have been the biggest problems in the past and has the Plugin possibly not closed a prominent security hole?

Conclusion: CSRF is old hat

Cross-site request forgery has been around since the beginning of the digital age. In addition, the number of cases is extremely small compared to e.g. Brute Force attacks.

This is also confirmed by OWASP's assessment that the attack is rather low profile, easy to detect, and serious only in certain specific cases. cases.

Nevertheless, it is good to know how the attacks work. Because the attacks often only work thanks to human error. Time and again, users open emails out of curiosity or click on links that they would have been better off not opening.

So, whether you're a user or an end-user, the best way to protect yourself from cross-site request forgery is with research and a little common sense.

Did you like the article?

Your rating helps us improve our future content.

Post a comment

Your email address will not be published. Required fields are marked with *.