CSRF, this abbreviation appears again and again in the update notes of the WordPress Core. The method behind it is now old hat and exploits the usually abundant cookies of a browser. 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 give you the option to stay logged in even after you have left the website. When you visit the website again, you don't have to enter your login data again, but are logged in directly. That's great, of course, because - just like password management or single sign-on - it saves you having to fill out forms.

The following happens in the background: When you log in to the website 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 string.

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

CSRF attacks are abuse of trust at their core

As you can see, the service that reads the cookies is fooled by a corresponding attack. How exactly this happens, I explain below with two examples.

The danger of this manipulation is that someone 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 - your trust in the senders of e-mails, for example.

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 is a reason for this: The non-profit organization OWASP (Open Web Application Security Project) regularly publishes a list of the ten most critical vulnerabilities in web applications. CSRF has slipped further and further down the list as a security risk over the years and has now disappeared from the top 10.

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, the security update 4.7.5 was published in May, which fixed six vulnerabilities that hackers could have used to attack via cross site scripting or cross site request forgery. However, cross-site scripting is often considered to be much more dangerous.

In addition, the issue of Cross Site Request Forgery tends to be more relevant for plugins and applications than for web design, agencies and SMEs. This is because protection against CSRF is also a question of programming. CSRF could become relevant, for example, for 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:

• The victim is tricked into loading a manipulated website or clicking on a link, for example by making it appear that the message is from a trusted person. Or human curiosity is exploited. In other words, phishing plays an important role in this type of attack.
• When loading or clicking the manipulated links or websites, the victim's browser executes an HTTP request without the victim noticing anything.

Two relatively simple examples illustrate how such an attack works.

Let's say Justus wants to transfer €100 to Bob via the www.bank.de website, and Skinny is sitting in wait to perform a CSRF attack. Skinny can use the GET or POST method for his attack.

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

• "Cross Site Request Forgery (CSRF)" - the OWASP review article.
• "Preventing CSRF Attacks In WordPress Using Nonces" - by qnimate.com

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 into www.bank.de and enters all the required data. The following (completely fictitious) input would be sent to the server:

GET http://bank.de/transfer.do?acct=BOB&betrag=100 HTTP/1.1

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

http://bank.de/transfer.do?acct=SKINNY&betrag=100000

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="http://bank.de/transfer.do?acct=SKINNY&betrag=100000">Wer dieses Rätsel nicht lösen kann, ist kein echter Detektiv!</a>

Or he sends him an e-mail 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="http://bank.de/transfer.do?acct=SKINNY&betrag=100000" width="0" height="0" border="0">

When Justus calls the link - consciously or unconsciously - the parameters are passed to the server, the transfer is triggered and €100,000 disappear from his account.

Of course, Justus has to click on the link while he is logged in. But if his browser unfortunately contains a login cookie from his bank, the attack will work even if he doesn't have the website open at the moment.

This is exactly what makes cross site request forgery so devious: Justus is probably not even aware that the cookie exists.

Cross site request forgery in POST method

The GET method can be used in links and is thus particularly easy to spread. 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.

It may sound a bit bulky, but you certainly know the use case, because forms work this way.

For our attacker Skinny, this means that he has to put in more effort, but he can still get to the goal.

Same scenario: Justus wants to transfer money to Bob. So he fills out the following form at www.bank.de:

<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">

</form>

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 then the transfer will be executed.

Skinny now deposits an invisible form on a manipulated website, for example:

<form method="POST" action="http://www.bank.de/geld_ueberweisen.php">

    <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!">

</form>

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

Attack via detours

That's why it's called cross site request forgery: the command is usually sent from another website. In order to attack website A, it deposits malicious code on website B. The victim is then lured to this website. Then he lures the unsuspecting victim here so that his browser executes the code.

How to secure yourself against CSRF attacks

The good news: Cross site request forgery has been known for ages. The risk is known and development is working specifically to eliminate it.

The bad news is that you can't actually protect yourself against it on the technical side. 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 from plugins. So you have to trust that a good job is being done in the development of the extensions you use.

That means specifically:

• Do not install too many plugins and only the plugins you really need
• Be careful with plugins that have not been updated for some time. Unfixed security vulnerabilities may be hidden here.
• Inform yourself beforehand about the plugins you install, for example about their compatibility with other plugins or the WordPress version you use (so that the plugin can also be updated).
• Update your plugins and the WordPress core regularly. Because the continuous updates are exactly there to close such security gaps.
• Be critical about phishing.
• If you are 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 plugin possibly not closed a prominent security breach?

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 brute force attacks.

This is also confirmed by the assessment of OWASP: Here, it is assumed that the attack is rather low spread, easy to detect, and serious only in very specific 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.

The best way to protect yourself from cross-site request forgery is to do some research and use some common sense.