Introduction to CSRF Exploitation

Before discussing the exploitation of CSRF vulnerabilities in detail, we will quickly recap the basics of CSRF and common CSRF defenses. For a more detailed explanation, check out the Session Security module.

Recap: Cross-Site Request Forgery (CSRF)

Cross-Site Request Forgery (CSRF) is a type of web attack where an attacker's payload forces a victim's browser to unintentionally perform actions in a vulnerable web application to which they are authenticated. CSRF attacks are typically performed by a payload on an attacker-controlled website, which sends cross-origin requests to the vulnerable web application. As such, the attack usually requires the victim to access the attacker-controlled website voluntarily or through other attack vectors, such as social engineering. In a successful CSRF attack, the cross-origin request is sent with the victim's session cookies and performs a change in the vulnerable web application.

As an example, consider the following scenario. The victim is an administrator of https://vulnerablesite.htb and is logged in to the site, i.e., the browser stores a valid session cookie. The site is not protected against CSRF attacks. The attacker controls a low-privilege account on the vulnerable web application and wants to execute a CSRF attack to obtain administrator privileges. When the victim accesses the attacker-controlled site https://exploitserver.htb, the site executes JavaScript code in the victim's browser that makes a cross-origin request to https://vulnerablesite.htb/promote?user=attacker. The browser sends the victim's session cookies with the cross-origin request such that the request is authenticated. Therefore, the web application promotes the attacker's user account to administrator, allowing the attacker to successfully execute a CSRF attack and obtain administrator privileges on the web application.

Although we will be creating the CSRF payloads manually in this module, there are tools that we can utilize for automatic payload generation, for instance the CSRF PoC generator here.

Recap: CSRF Defenses

There are many different defensive mechanisms to protect against CSRF attacks, most of which rely on restrictions posed by the Same-Origin policy. We will briefly recap different options for CSRF protection.

CSRF Tokens

CSRF Tokens are unique and random values that must be included in requests performing sensitive changes to the web application, for instance, when submitting HTML forms. The token must be unpredictable, so an attacker cannot know its value in advance. Furthermore, the web application needs to check the value of the CSRF token before performing the sensitive change. This prevents the attacker from constructing a cross-site request that the web application accepts. The token must be unpredictable, checked adequately by the backend, and not sent in a cookie, as otherwise, the CSRF token protection may be ineffective.

In our above example, the web application would only accept user promotion requests containing the username in the user GET parameter and the CSRF token in the csrf_token GET parameter, typically a hidden value in the HTML form. Since the CSRF token is a random value, the attacker cannot know the correct value, and thus, he is only able to construct a cross-origin request with an invalid CSRF token. If the web application checks the CSRF token correctly, the request will be rejected, so the attacker user account is not promoted to administrator privileges.

HTTP Headers

Alternatively to CSRF tokens, web applications may use HTTP headers to protect from CSRF attacks. For instance, a web application may check the Origin or Referer headers to block cross-origin requests and thus prevent CSRF attacks.

Web browsers typically add the Origin header to cross-origin requests to indicate the target origin where the request originated from. An attacker cannot control this behavior. Thus, a web application can check the value of the Origin header to determine if a request originated from another origin and can subsequently block state-changing cross-origin requests to prevent CSRF attacks.

The same methodology can be applied to the Referer header, which is typically added by web browsers to indicate the URL a resource was requested from.

SameSite Cookies

Another CSRF protection mechanism is the SameSite cookie attribute (originally drafted in this Internet Draft and subsequently updated in another Internet Draft). A web application can set this attribute to configure if the cookie should be sent along with cross-origin requests. The attribute can have the following values:

• none: no additional measures are enforced by the browser. The cookie is sent with all cross-origin requests

• lax: the browser only sends the cookie with some cross-origin requests. For instance, only cross-origin form submissions using GET. The cookie is not sent with any cross-origin requests made from JavaScript

• strict: the browser does not send the cookie with any cross-origin requests

Most modern browsers enforce a SameSite attribute of Lax by default (i.e., if no SameSite cookie attribute is explicitly set). This prevents many CSRF attacks by default, as the browser only sends cookies with safe HTTP requests, which prevents POST-based CSRF attacks. GET-based CSRF attacks are still possible but significantly less common than POST-based CSRF attacks.

Generally, web applications are recommended to implement CSRF tokens as their primary CSRF defense. SameSite cookies and header-based checks may also be employed as additional defense-in-depth protection measures.