CSRF Where Token Validation Depends on Request Method
Cybersec Café #13 - 4/30/24
Welcome back to the Methodology Walkthrough at the Cybersec Cafe, where we take a deep dive into the hacker's mindset. Join us every Tuesday morning as we tackle different complex cybsersecurity topics and walkthrough different hacking techniques.
Objective
Construct and host an HTML page that leverages a CSRF attack to change the victim email.
What is Cross-Site Request Forgery?
Cross-Site Request Forgery (CSRF) is a vulnerability that tricks a user's browser into performing actions on a web application without their consent. This occurs when an attacker crafts a malicious request and persuades the user to unknowingly execute it while authenticated on the target application. CSRF attacks typically exploit the trust relationship between the user and the site, allowing the attacker to manipulate the user's session and perform actions like transferring funds, changing passwords, or making purchases without their knowledge. CSRF poses a serious threat to web applications, as it can lead to unauthorized transactions, data breaches, and compromised user accounts.
Methodology
The Recon
The first step to any hacking session is to gain a thorough understanding of the application in front of us.
In more complex applications, you may find it beneficial to create mind-maps or notes to keep track of the different complexities you come across.
Let’s start by clicking around the application to see what features are available to us.
The application is a blog:
We can see that each photo also has a comment feature.
Another important part of the recon process is to send test requests whenever actions have been identified. So, let’s send a test comment here to capture the request in our instance of Burp Suite.
Next, there is an account feature available. We’ve been provided with credentials to login - let’s go ahead and authenticate to the application.
Inside, we can see that there is the functionality to change our email.
As we did before, let’s perform a test of this function to capture the request inside of Burp.
It seems we’ve exhausted all of the features available to us in the application.
Let’s head over to our Site Map to get a holistic view of what we have in front of us.
It seems that there are only 2 real endpoints of interest to us here: Change Email and Post Comment.
Based on the Objective for this lab, the Change Email endpoint will likely be our attack vector.
If you have Burp Professional installed, you can right-click on the request and kick off an active scan.
Let’s inspect the request itself:
From a quick glance, we can see that the request has a CSRF token attached in the body.
It looks like we’ve found our attack vector.
But, touching back on the objective: we need to construct and host an HTML page.
Luckily, the lab also supplies us with an Exploit Server where we can host a page and deliver it to our victim.
To complete our Recon phase, kick off scans on the remaining of the endpoints of interest. In this case, we can scan the Post Comment and Root requests.
Testing
Send the Change Email request to the Burp Repeater.
Here, we can manipulate the request manually and determine if the request may be vulnerable to a CSRF attack.
First, send the request to get a baseline response - it should return a 302 Found response meaning the request went through.
Next, let’s try removing the CSRF token to see if we get any different behavior:
As we would expect, the removal of the token causes the request to get rejected, returning a 400 response.
But, what if we combine this approach with another technique?
Let’s try to trick the application by changing the request to a GET request rather than a POST request.
On the same request that has the CSRF token removed, right-click and use the Change request method option in the menu:
The request will visually change, not only changing from a POST to a GET, but moving the body content to become parameters of the request.
Send this new GET request to observe any differences in the response.
We can see that it now returns a 302 - the same response we got with our baseline request! That means the request worked - we can now take advantage of our victim.
Exploitation
Now that we have a valid request for our own account, we can construct an HTML page that we can deliver to our victim to take advantage of their authenticated instance.
We can construct this attack in one of two ways:
If you have Burp Professional, right-click and navigate to Engagement tools > Generate CSRF PoC. Click Copy HTML.
<insert photo 9>If you have Burp Community, copy the following code and update the action URL to match your lab scenario.
<html> <body> <form action="https://lab-id.web-security-academy.net/my-account/change-email"> <input type="hidden" name="email" value="test@email.com" /> <input type="submit" value="Submit request" /> </form> <script> history.pushState('', '', '/'); document.forms[0].submit(); </script> </body> </html>
Whatever option you choose, navigate to the Exploit Server in your instance and paste the HTML code in into the Body section.
In the context of this lab, you can change the email to any arbitrary value as long as it follows an email structure.
However, in a real-life scenario, you would want to change the victim’s email to an email you control. This would allow you to take full control of their account.
When ready, click Deliver exploit to victim.
What We’ve Learned
In this walkthrough, the dangers of improper CSRF implementation are on full display. We were able to take a simple misimplementation and turn it into a full account takeover of a victim user. CSRF functionality was created to prevent attacks like this, so from a developer’s perspective, it’s important to ensure that implementation follows best practices.
Want to give the lab a try yourself? You can check it out on PortSwigger’s website here.
Securely Yours,
The Cybersec Cafe
Just a heads up, The Cybersec Cafe's got a pretty cool weekly cadence.
Every week, expect to dive into the hacker’s mindset in our Methodology Walkthroughs or explore Deep Dive articles on various cybersecurity topics.
. . .
Oh, and if you want even more content and updates, hop over to Ryan G. Cox on Twitter/X or my Website. Can't wait to keep sharing and learning together!