Guide 03 in Sarah’s Welcome to Web Security Series #

In this series, Sarah discusses some common vulnerability classes found in web security and how you can find and exploit them. Today’s focus is cross-site request forgery (CSRF), a close cousin of XSS that is somewhat less destructive due to its inherently limited scope.

Introduction #

Cross-Site Request Forgery, commonly shortened to CSRF, is a vulnerability that forces a victim user to perform unintended actions on a site for which they are authenticated (i.e. ’logged in to’). Due to its ‘cross-site’ nature, it is often confused with XSS though there are a few distinctions between the two. Generally, CSRF is typically less dangerous than XSS as it is inherently limited by the fact that what it can do is controlled by the victim user’s privilege level. As CSRF effectively ‘hijacks’ a user’s actions, if they are only a normal user, they can only perform actions that a normal user could do whereas XSS can allow attackers to issue requests, read responses and exfiltrate data. CSRF is also limited by the fact that websites generally implement good CSRF defences and only a handful of user actions are left unguarded.¹

Finding CSRF Vulnerabilities #

For a CSRF vulnerability to arise, a few conditions must be met. The first condition is there must be some action(s) that a user can perform that an attacker can hijack. If the victim is a normal user, this targeted action might be changing their email address or password for an online account. If the attacker targets a privileged account, such as that of an administrator, then the targeted action could involve changing other users’ permissions or modifying their data. Without this specific action, a CSRF attack will not be possible.

Secondly, the application must only use session cookies as a means of authentication and identification. In other words, the application does not have other methods to track the sessions or validate user requests. More complex CSRF attacks can partially bypass certain defences which use more than session cookies (such as SameSite cookies and referrer validation) but this is only true in cases of misconfiguration or weak configuration.

Finally, the HTTP requests that execute the action must be predictable. In other words the attacker must know, or be able to guess, the precise parameters required to perform the action.

If these three conditions are met, then there is a chance that the application is vulnerable to a CSRF attack.

Exploiting CSRF Vulnerabilities #

Unfortunately, CSRF can be a challenging vulnerability to exploit as it requires the attacker to craft a tailored HTML script. A fairly simple payload could look like this:

<form  action="https://vulnerable-website.com/my-account/change-email" method="POST"> 
	<input type="hidden" name="email" value="get-pwned@evilhacker.net"/> 
	<input type="submit" value="Submit request"/>
</form> 
<script> 
	document.forms[0].submit(); 
</script>

If a victim visits this page while logged in to the vulnerable service, their email will be changed to get-pwned@evilhacker.net (assuming the site has no defences against CSRF). To actually get a victim to visit the page, an attacker would embed the HTML into some web site they can control and then send a link to the victim. As soon as the user clicks on the link, the script should run and trigger the attack. In some extremely basic CSRF attacks, it might not even be necessary to create a HTML payload. The exploit could be contained in a single URL on a vulnerable site like this:

<img src="https://vulnerable-website.com/email/change?email=get-pwned@evilhacker.net">

However, this is not a common occurrence. In fact, CSRF vulnerabilities are generally less common as they are very ’targeted’. They focus on the actions of one user and unless that user is a privileged user, the consequences are often limited to an individual level.

Defending Against CSRF #

Another reason why CSRF attacks are less common is that they are relatively easy to defend against, particularly compared to XSS vulnerabilities which are also more dangerous. Moreover, a lot of defences for XSS can actually also counter CSRF. Once again, OWASP has an excellent cheat sheet that lists many defences against CSRF. However, here is a shortlist of defences:

• Use your framework’s in-built CSRF protections or if it is not built in, add CSRF tokens to any requests that cause actions²
• Use SameSite cookies, which are essentially special mechanisms that determine when a website’s cookies are coming from another website. Since 2021, Chrome imposes Lax SameSite restrictions (Strict is the next level up) by default. However, misconfigured SameSite cookies can be easily bypassed
• Implement additional user-interaction steps before performing a sensitive action. This could be a CAPTCHA, requiring the password to be entered again, a one-time token, etc
• Use standard headers to verify origin. Much like SameSite cookies, this can be an effective defence but it requires careful configuration as weak validation can be bypassed easily
• Avoid using GET requests for an operation that causes actions

Conclusion #

At first glance, one may wonder why one would ever use CSRF when XSS can be performed as CSRF is generally better defended and is more limited in scope. A very simple answer to that is that CSRF does not require an attacker to completely compromise the target site, which makes it a bit simpler. Moreover, it can be easier to perform unwanted actions through a CSRF attack rather than having to put together a complex script to inject with XSS. In fact, some may argue that CSRF vulnerabilities are easier to identify as one only has to analyse the requests associated with the target action, rather than the website’s entire framework (as may be required in a complex XSS attack). If an attacker’s goal was to simply send a malicious link to induce users to transfer money from their bank account to an attacker’s account, then CSRF would probably be a simpler and easier option. Therefore, it should not be written off as a ‘budget XSS attack’ as there are certainly times when it would be the preferred attack vector.

If you are interested in learning more about CSRF and web security, the PortSwogger WebSecurity Academy is a fantastic resource. You can create a free account and explore their labs here.