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:

• A web application containing CSRF vulnerabilities as well as functions that are of interest to the attacker in some way.
• A user who can be authorized in the web application.
• The user’s browser, which makes the attack possible in the first place.
• An HTTP request engineered by the attacker. This contains the request sent to the web application to carry out an action on behalf of the attacker. This is where the term forgery comes from (in the sense of counterfeiting but also shaping, building).
• The attacker’s social engineering skills for manipulating the user into executing the engineered request.
• A carefully timed attack, as the constructed request will only be successfully executed if the user is logged into the desired web application at the time.

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

• Cross-site requests: One characteristic of browsers is that they can carry out cross-site requests. This mechanism allows the browser to load content from third-party websites additional to the website actually accessed. This often takes the form of images, advertisements or scripts. Without any action by the user, this content is requested and integrated by the browser using HTTP requests. This explains the term cross-site request forgery attack.
• HTTP state management mechanism: Because HTTP is a stateless protocol, session cookies may be set to create a state. These are stored in the browser as soon as a user is successfully authorized by the web application. From that point on, these session cookies are sent by the browser with every request to the web server of the web application. The web application checks this cookie to ensure that the user is authorized to carry out actions in the browser as an authorized user. After a logout or session timeout, the cookie is destroyed, and the web application will no longer accept actions performed by this authorized user.

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:

• Using the CSRF token in combination with a check for origin of the request
• Consistent setting of the SameSite cookie attribute
• Explicitly requesting user input before an action can be carried out
• CSRF token and comparing source and target origin. This is a combination of various measures for preventing CSRF attacks. A check should be run to ensure that the source and target origin information of the relevant server headers (OWASP Secure Header Project) are consistent, while explicit CSRF tokens should be used as well.

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:

• Double-cookie defense
• Encrypted token pattern
• Custom header, e.g. X-Requested-With: XMLHttpRequest

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

• http://www.cap-lore.com/CapTheory/ConfusedDeputy.html
• https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_header_name
• https://scotthelme.co.uk/csrf-is-dead/
• https://tools.ietf.org/html/rfc7231#section-4.2.1
• https://vuldb.com/?search
• https://www.owasp.org/
• https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
• https://www.owasp.org/index.php/OWASP_Secure_Headers_Project