Cookies as a Threat: Cross-Site Request Forgery

Tobias Schüring Updated on 21.01.2020
7 Min.
Cross-Site Request Forgery (CSRF) attacks WordPress are among the oldest attacks of all.

CSRF, this abbreviation appears repeatedly in the security and maintenance updates of the WordPress -Core. The method behind it is now old hat and takes advantage of the abundant cookies of an Internet user. Fortunately, it is quite easy to protect yourself from Cross-Site Request Forgery. All you need is a little time and attention.

You probably also use a number of services where there is an option to stay logged in even after you have site left them. If you visit them site again, you do not have to enter your login data again, but are logged in directly. This is of course great for the user, because it is - just like a password management or a so-called Single Sign-on - tiresome form filling out.

The following happens in the background: When you site log on 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. If you stay logged in, it 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. Which, by the way, is why you'll be logged out everywhere when you Browser Cache empty. This is because all cookies are also deleted during this process.

A CSRF attack is essentially an abuse of trust

You already notice: With a corresponding attack, the attacker feigns something to the service that reads the cookies. How exactly this happens is explained below using two examples.

The danger of this manipulation lies in the fact that a third party, i.e. the attacker, for example, makes changes to your Facebook profile in your name. However, Cross-Site Request Forgery is also frequently dependent on phishing. So trust becomes relevant here as well - namely your trust in e.g. the sender of mails.

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

How endangered is WordPress ?

You have probably not heard the term Cross-Site Request Forgery as often as Brute Force Attacks , 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. On the preliminary list for 2017 CSRF occupies 8th place out of 10. In 2007 and 2010 the attack still landed in 5th place, In 2013 it rose to 8th place off.

One reason for this is probably that CSRF attacks are almost as old as the Internet itself. Professional developers are now skilled in securing their code against this. So security risks are quite easy and quickly fixed.

With WordPress one is also on guard. For example, in May the security update 4.7.5 was released, which fixed six vulnerabilities that could have been used by hackers via cross-site scripting or cross-site request forgery. Often but yet cross-site scripting is considered to be much more dangerous.

In addition, the question of Cross-Site Request Forgery tends to be more for Plugin- and application developers than for web designers, agencies and SMEs. Because protection against CSRF is also a question of programming. CSRF could be relevant, for example, for in-Plugin-will be bought.

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 gets the victim to load a manipulated site one or click on a link, for example by pretending to be a trusted person or by 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.

Let's assume that Justus wants to talk to Bob about site www.bank.de Transfer €100 and skinny will be on the lookout for a CSRF attack. Skinny can now use the GET or POST method for his attack.

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

Cross-Site Request Forgery for 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 added to the URL. And as we have already heard from SQL Injections know: A URL is relatively easy to manipulate.

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

GET http://bank.de/transfer.do?acct=BOBetrag=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=SKINNYetrag=100000

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

">If you can't solve this mystery, you're not a real detective !

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

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 he is logged in. However, if unfortunately there is a login cookie of his bank in his browser the attack will work even if he hasn't opened itsite .

This is exactly what makes Cross-Site Request Forgery so devious: The injured party 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 therefore particularly easy to spread. This naturally plays into the hands of the attacker in terms of distribution. However, providers can now ensure that GET requests are not given write permission on principle.

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

It may sound a bit bulky, but I'm sure you know the application. Because forms work this way.

For our attacker, Skinny, this means that although he has to make more effort, he can still reach his goal.

Same scenario: Justus wants to transfer money to Bob. So he fills up www.bank.com the following form:

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

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

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

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

    <input type="submit">

form>

This sends the command geld_ueberweisung.php which looks like this

if(isset($_FORM["from"]) && isset($_FORM["on"]) &&isset($_FORM["crowd_in_euro"]) && isset($_CMOKIE["user_logged in"]))

{

    transMoney("from", "on", "amount");

    echo "Transfer successful!";

}

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

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

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

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

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

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

    <input type="submit" value="Who cannot solve this mystery is not a real detective!">

form>

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 by devious means

Hence the name Cross-Site Request Forgery: The hacker usually sends the command from anothersite . So to attack site A, he deposits malicious code on site B. He then lures the unsuspecting user here so that his browser can execute the code.

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

How to protect yourself against CSRF attacks

The good news: Cross-Site Request Forgery has been around for ages. Developers are aware of the risk and work 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.

This means concretely:

  • Do not install too many plugins and only the plugins that 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 are critical of phishing
  • If you're unsure, take a look Plugin in the WP repository. What are the ratings, what were the biggest problems in the past, and did the Plugin a high-profile security breach may not have been closed?

Conclusion: CSRF is old hat

Cross-Site Request Forgery has been around virtually since the beginning of the digital age. In addition, the number of cases is higher than in e.g. Brute Force Attacks extremely small.

This also confirms the assessment of the OWASPHere, it is assumed that the attack is rather small, easy to detect and only in certain specific cases serious is.

Still, it's good to know how the attacks work. Often the attacks only work thanks to human error. Again and again, users open mails out of curiosity or click on links that they should not have opened.

So whether you're a user or an operator, the best way to protect yourself from Cross-Site Request Forgery is to use research and a little common sense.

Related articles

Comments on this article

Write a comment

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