Featured next in WWWWWH, a series where we dive into the Who, What, When, Where, Why, and How of different vulnerabilities, we’ll be exploring Cross-Site Request Forgery (CSRF). If you’re new to the WWWWWH series, the purpose is to look past just the technical details of vulnerabilities that many of us solely focus on at times (myself included), and to instead view them from an end-to-end perspective. Performing this exercise illustrates how these vulnerabilities would look when researching in the real world. Let’s get into it and learn about the full methodology to weaponize CSRF.
Cross-Site Request Forgery (CSRF)
Cross-Site Request Forgery is a web vulnerability that takes advantage of a same origin policy mechanism, or lack thereof, allowing attackers to trick victims into performing actions that they don’t intend to. What does this mean exactly? This means an attacker can get victim users to perform actions on their behalf - to gain control of their account, escalate privileges, or even more critical actions if proper controls aren’t in place. But you won’t be coercing your victims to perform these actions over the phone by spoofing the phone number of a bank. Instead, the CSRF vulnerability takes advantage of the CSRF token - a unique, secret, and unpredictable value generated by server-side functionality and shared with the client. Users must include the correct CSRF token when performing certain requests. If these tokens are implemented correctly, they can prevent this attack and make it very difficult to exploit and weaponize against users. However, they aren’t always implemented correctly. Let’s analyze this vulnerability more.
WWWWWH Analysis
Who
CSRF attacks are most effective when targeting a user that has permissions for high privilege actions you may want to perform. The perfect victim of a CSRF attack would be an administrator account. In an application, this could allow you to trick the user to escalate privileges, delete data, or create resources. Outside of an application like this, there are other use cases for CSRF, including combining the attack with phishing to trick a user into sending money, making payments, or changing account information. But, exploitation in these scenarios is much more difficult to pull off with the protections applications and browsers have in place these days.
What
A CSRF vulnerability at it’s simplest form gives the attacker the ability to trick a victim user into performing an action on your behalf. If done well, this can generally happen without the victim even realizing, and actions can be irreversible by the time they do. The attack can be considered a “one-way” vulnerability, meaning you can trick a user into performing an action, but you won’t necessarily receive any response from their action confirming it.
When
In order for a CSRF vulnerability to be possible, there are 3 general conditions that must be in place. First, there must be a relevant action that you are inducing the victim to perform. Second, there must be no cookie or session based handling, which are mechanisms generally in place to validate requests, identify users, and protect against this attack. Lastly, there can’t be any unpredictable parameters, as this would make it difficult, if not impossible to craft an exploit. If all 3 of these conditions are met, then a CSRF attack can be delivered to the victim. CSRF attacks are generally best served when they are using the app you want them to perform the action on, reducing suspicion.
Where
Attacks can be delivered in many different ways, but you’ll want to search for mechanisms in an app or through social engineering to determine the best vector. Vectors can be found in places such as comment sections, emails, or text messages. It’s here you can feed users a link or payload, attempting to get them to interact with it.
Why As mentioned above, CSRF attacks are going after an action you want the victim user to perform on your behalf. If attempting this exploit on a SaaS app a company uses holding sensitive data, this can come in the form of administrative actions - such as CRUD functions to disrupt business operations or escalation of privileges for an account you control. In an account takeover scenario, you could social engineer users into changing their email to an email you control. After the email change has gone through, a password reset (commonly available in most apps) could lead to full account takeover after receiving the password reset email to your controlled email. In the most severe of scenarios, these attacks can be used to exfiltrate or wire funds from the victim to hacker controlled accounts.
How
First, you’ll need to figure out a way to deliver your payload to the victim. Whether that be some form of code injection or social engineering, you’ll need to induce a victim to take an action on your payload.
As an attacker, this is a difficult vulnerability to take advantage of these days due to the many protections in place now. However, there are a few avenues you can take when attempting to bypass protections. Some techniques include switching to the GET form of a request, removing the parameter entirely, attempting to obtain a valid token from an account you control to deliver to the victim, or invent a token if the formatting is obvious. There are other techniques as well, but these are some of the simplest, yet still effective ways to try.
Let’s look on an example where the validation of the token depends on the method of the request.
As an attacker, imagine you log into an online marketplace app and start probing around your account page. You realize there is a change email feature that doesn’t have any validation outside of you being currently logged in to your account. So, you start testing the request.
It looks like a POST request with a CSRF token attached to initiate the change email functionality.
POST /my-account/change-email HTTP/2
Host: cyberseccafe.com
Cookie: session=xxxCookiexxx
Content-Type: application/x-www-form-urlencoded
Content-Length: 61
Origin: https://cyberseccafe.com
Referer: https://cyberseccafe.com/my-account?id=testUser
email=test%40cyberseccafe.com&csrf=hSYMwUK3URtJzrxZMBsg7tOIAwuRKeRJFirst step in validating a vulnerability is performing it on yourself. So, we can start by trying one of our techniques. Removing the token entirely doesn’t seem to work. But as mentioned in one of the bypass methods above, we can try changing the method to a GET.
GET /my-account/change-email?email=test2%40cyberseccafe.com&csrf=hSYMwUK3URtJzrxZMBsg7tOIAwuRKeRJ HTTP/2
Host: cyberseccafe.com
Cookie: session=xxxCookiexxx
Origin: https://cyberseccafe.com
Referer: https://cyberseccafe.com/my-account?id=testUserThis seems to work and change my email, but it still has a token involved. But, what if we combine this with the previous bypass technique we tried and remove the token entirely? It’s possible then we can have an attack vector via the GET request with no token for validation.
GET /my-account/change-email?email=test3%40cyberseccafe.com HTTP/2
Host: cyberseccafe.com
Cookie: session=xxxCookiexxx
Origin: https://cyberseccafe.com
Referer: https://cyberseccafe.com/my-account?id=testUserIn our example, we can see the email switch still goes through - meaning there is insufficient CSRF token validation going on.
The next step is to craft our payload. Burp Suite has functionality to generate a demo payload, and one for our attack could look like this:
<html>
<body>
<form action="https://cyberseccafe.com/my-account/change-email">
<input type="hidden" name="email" value="attacker-controlled-email@email.com" />
<input type="submit" value="Submit request" />
</form>
<script>
history.pushState('', '', '/');
document.forms[0].submit();
</script>
</body>
</html>This payload is a very simple button that will perform our action to change to an email controlled by us. If successful, we’ll now have the victim user’s account registered to us without them knowing. From here, we could initiate a forgot password sequence, which should now send the recovery email to our controlled email, allowing us to perform a full account takeover.
In an actual attack scenario, it would be very difficult to get a user to perform an action by just sending them this button, so it’s likely you’d want to deliver the payload through a more detailed attack vector, like this through a phishing attack or comment section on the target site.
While this is a very basic illustration of this attack, it perfectly shows the need to properly implement CSRF protections.
WWWWWH
As you can see, Cross-Site Request Forgery is an interesting vulnerability that can have severe consequences if protections aren’t implemented correctly. But, there are also protections in place nowadays that can completely mitigate this threat. Here are some common ways to improve security against CSRF attacks:
CSRF Tokens - Proper implementation and validation makes it difficult to exploit this vulnerability.
SameSite Cookies - A browser mechanism that determines when included cookies originate from other websites. This is a proposed standard, but currently only enforced by Chrome at the time of writing this.
Referer-Based Validation - Make use of the Referer Header in requests to verify where the request originated. This is generally less effective than CSRF token validation.
Hopefully this has brought you value in your research, and you can see the critical implications finding a CSRF vulnerability can have!
If you’ve enjoyed this analysis of the Cross-Site Request vulnerability and are interested in more, you can check out other vulnerabilities I’ve covered in the WWWWWH series. Or, if you’re looking for daily cybersecurity content, consider checking me out on Twitter/X. And as always, this material is meant to be used for educational purposes and not for malicious practice.
Comentários