Cross-site request forgery - Is CSRF dead?

Cross-site request forgery

Is CSRF dead?

Dominik Altermatt
by Dominik Altermatt
on September 21, 2017
time to read: 11 minutes

Keypoints

  • CSRF stands for cross-site request forgery
  • This is a technique used for attacking web applications
  • By inadvertently calling a resource externally, a legitimate user may carry out an action involuntarily
  • Advanced settings for cookies reduce the possibility of attack
  • Dynamic CSRF tokens can prevent this type of attack

Cross-site request forgery (CSRF) attacks have been around for some years now, and they offer an interesting approach for carrying out privilege escalation in a web application. The basic concept behind this attack method was mentioned as far back as 1988 in an article by Norm Hardy, who called it the confused deputy problem. The article discusses how an attacker might gain access to a resource through a deputy. While the user himself might not have privileges for the resource, he can use the privileges of the deputy and carry out actions accordingly.

The goal

With a CSRF attack, the attacker causes actions to be carried out in a web application in the name of an authorized user. This opens up a broad range of uses – everything from posting comments on social media to clicking on specific content on the Internet (influencing trends or click-financed advertising models). Things get far more critical when a CSRF attack is used, say, to make payments with online banking, or to create privileged users in a management console of a resource in order to then carry out further attacks or manipulations.

One look at VulDB (search for CSRF) shows that new CSRF vulnerabilities are being identified on an almost daily basis. Many of them are categorized low, some as medium and very few as high according to the Common Vulnerability Scoring System (CVSS). Nonetheless, a CSRF attack should be taken seriously, precisely because it is not excessively complex and there are no major requirements of an attacker profile for carrying out these attacks in a simple form.

Structure of the attack

The components involved in a CSRF attack are:

The behavior of the browser is particularly important in CSRF attacks. Here there are two factors worth mentioning:

Possible attack scenario

So now it’s easy to imagine how a CSRF attack might unfold. One possible scenario could go like this:

  1. An attacker has a website under his control. This website contains cross-site requests. However, this doesn’t just load images from third-party websites, but rather CSRF requests, which could, for instance, set the user’s password to 123abc.
  2. With a bit of social engineering and good timing, the attacker can now manipulate the user to visit the dubious website. Perhaps the user is a fan of fine watches, and the attacker’s website contains cheap watch offers. When the watch website is loaded, cross-site requests are also executed through the browser.
  3. At the same time, the user is authorized by the target web application. Because the user’s browser can’t tell who submitted the request Change password to "123abc", the browser adds the session cookie to the engineered request and sends it to the web application.
  4. With no way of telling whether a request was triggered by legitimate user input or a CSRF attack, the web application changes the user’s password to 123abc.
  5. The attacker can now log in as this user and carry out other manipulations under the user’s name.

Note that use of the session cookie should be seen as a characteristic of the CSRF attack, otherwise known as session riding. Nor do CSRF attacks exclude other session identifiers either, such as basic/digest authentication.

Below are a few basic examples of HTTP requests for changing Bob’s password for the web application management-console.example:

Simple GET request:

GET http://management-console.example/change_pwd.do?usr=BOB&paswd=123abc HTTP/1.1

Fake image:

<img src="//management-console.example/change_pwd.do?usr=BOB&paswd=123abc" width="0" height="0" border="0">

PUT request:

PUT http://management-console.example/change_pwd.do HTTP/1.1
{ "usr":"BOB", "pwd":"abc123" }

Protection against CSRF

The OWASP recommends several different approaches for protecting yourself against CSRF attacks:

To check whether the source and target origin are consistent, you can use the standard server headers Referer, Origin and/or Host. Once you have evaluated the source and target origin, comparing them is simple. If they don’t match, the request should be blocked to prevent a CSRF attack. Server headers are generally easy for an attacker to manipulate. However, the aforementioned headers are slightly more protected, as they are included in the forbidden header name list. That means that these headers cannot be set on the browser side with JavaScript, which protects them from XSS attacks.

However, a comparison of existing server headers does not provide sufficient protection against CSRF attacks, which is why a matching CSRF token is necessary. A CSRF token should be sent with every action that can result in a change of status. The same applies to session cookies, although not for the whole session, but rather generated anew with each request. In principle, the same requirements of complexity and entropy apply to both CSRF tokens and session cookies.

Among CSRF tokens, on the other hand, there are various approaches. Here the OWASP names the following options:

Modern frameworks for web developers usually provide CSRF token functions already. These should, therefore, be used as the first line of defense. Should these protective measures prove insufficient, you can also use specially designed CSRF token concepts.

Same-Site Cookie Header

Another option for protecting a web application against CSRF attacks is the consistent use of the SameSite cookie attribute, something that Scott Helme recommends in one of his articles. There he proclaims that the CSRF is dead, or at least no longer exploitable, as long as the session cookie’s SameSite cookie attribute is consistently set.

Set-Cookie: sess=abc123; path=/; SameSite

The SameSite cookie comes in two versions: strict or lax. Unless explicitly specified, the mode is set to “strict” by default.

SameSite=Strict
SameSite=Lax

By setting the SameSite (default/strict) attribute, the browser is told never to open requests that come from a cross-site source. However, this may also have undesirable effects for the site operator. Should a user be logged on to a website and wish to open another tab in the browser from the same site, this tab will not already be logged into the relevant website, as it usually would be.

That’s why there is also a lax mode, which contains an exception for the browser and the way it treats the sending of cookies. Specifically, the browser may send requests to top-level domains, for instance (from the website where the user is already logged in), but only with HTTP methods that are considered secure.

Requesting user input

For certain cases, it may also be a good idea to consider explicitly requesting user action before permitting critical actions, such as resetting a password. Here you can use CAPTCHA, one-time tokens or re-authentication.

Conclusion

CSRF attacks exploit a vulnerability which is included in the structure of websites and the behavior of the browser by design. A well-planned CSRF attack, complete with an effective social engineering campaign, can cause major damage – perhaps in the form of a privilege escalation as a key intermediary stage for a multi-stage attack. Various precautions can be taken. While it may be too soon to write off CSRF completely, using the SameSite cookie attribute is quick to implement and is highly effective. Introducing CSRF token concepts requires more work and should be considered carefully. Most modern web development frameworks already offer relevant functions for this. If you do use a CSRF token, it is essential that the token is properly checked on the server side and that the request is rejected if the details not match.

About the Author

Dominik Altermatt

Dominik Altermatt is working since 2003 in the IT business and was responsible for Data Leakage Prevention at a Swiss bank for many years. Besides traditional penetration testing he is also focusing on the introduction and improvement of IT security management processes. (ORCID 0000-0003-4575-4597)

Links

You need professional Vulnerability Management?

Our experts will get in contact with you!

×
TIBER-EU Framework

TIBER-EU Framework

Dominik Altermatt

You want more?

Further articles available here

You need support in such a project?

Our experts will get in contact with you!

You want more?

Further articles available here