Welcome to the first installment of “Attacks You Should Know About!” In this series of blogs, we will cover a variety of web application attacks that are fundamental for web application penetration testers to know about. If you’re already familiar with them, great! This will serve as a valuable refresher or an additional resource on the subject. If you’re new, the goal is to provide you with a clear understanding of what the attack is, what it can do, how to mitigate it, and, finally, a proof of concept. Let’s start by learning about Cross-Site Request Forgery.

What is Cross-Site Request Forgery?

Cross-Site Request Forgery (CSRF) is a web application vulnerability that tricks users into performing unintended actions without their knowledge. This often includes changing email addresses, passwords, or any other state-changing actions on the vulnerable application. The nature of a CSRF attack is based on the trust the browser has in the user. A threat actor forges a malicious request, embeds it into a website, email, or another form of content, and lures the victim into executing the malicious request. Since the user is authenticated via a session cookie, the application believes the request is from the user and executes the threat actor’s desired actions. CSRF attacks are most effective and commonly seen paired with phishing attacks.

Both OWASP and Portswigger Web Academy are excellent resources for learning about the in depths techniques to preventing CSRF attacks.

Impact of CSRF Attacks

CSRF attacks are limited in the sense that they can only perform state-changing actions within the targeted web application. However, there are a number of powerful actions a CSRF attack can accomplish, examples being:

  • Changing account settings (turning MFA on/off or other features)
  • Altering user data (email addresses, passwords, mailing addresses, etc.)
  • Performing transactions
  • Submitting forms
  • Modifying, creating, or deleting application data

Performing a CSRF Attack

For this example, let’s assume we have decided to target the following web application:

This application uses the Advanced Electron Forum (AEF), a free, open-source bulletin built off of MySQL and PHP. It would be rare to see AEF in the wild, as it’s been over a decade since updates have been pushed out, but not impossible to encounter. Due to it being such an old service, seeing this kind of forum should instantly set off some red flags as a penetration tester. At the bottom of the page, we see this version is AEF 1.0.9. Let’s check to see if there are any CSRF vulnerabilities present in this application.

In this case I used Exploit Data to search for known AEF 1.0.9 vulnerabilities. From there, you can either copy the payload directly from Exploit DB, or use “searchsploit” in Linux to directly pull the HTML file we will be using.

We were able to determine from the exploit details is that this version of AEF has no CSRF protections in place. Note that this is simplified for this demonstration. In real-world scenarios, it will be up to you as a tester to determine if proper CSRF protections are in place or not.

Let’s go ahead and begin crafting our malicious request. We are going to demonstrate how to break the connection between the application and its database.

Before we send this malicious file to our victim, let’s better understand why we decided to target the MySQL settings.

For this scenario, we know that these are the HTML key-value pairs we are targeting since they are standard for this version of AEF. As the attacker, I would want to change all of the key-value pairs to something I want. The username and password fields would give me access to the database, and changing the server field to something that doesn’t exist could break the database connection. From here, all we have to do is change our values to whatever we want and send it to our victim.

Remember, the victim must already be authenticated to the application. If a session does not currently exist, our forged request will not be successful.

Victim POV

Let’s see how this plays out on the victim’s end. The administrator currently has a logon session to AEF.

The administrator receives an email from someone claiming to be a customer. They have attached an HTML to the email and requested the admin to open it with their browser. Of course, in a real-world scenario the file would most certainly not be named “csrf_poc”, but rather something more believable.

The administrator, attempting to fulfill their customer’s request, follows the instructions and opens the HTML using their browser.

Since the victim had an active session, the request was successfully sent and the CSRF attack was properly executed. We see that the MySQL settings have been changed to what the adversary predisposed them to be.

Furthermore, the adversary has also broken the connection from the MySQL and AEF. The web application can no longer be accessed by anyone, effectively causing a denial-of-service.

Mitigating CSRF Attacks

While CSRF attacks are undoubtedly powerful, it is very common to see anti-CSRF defenses in place on most web applications today. One very common mitigation are CSRF tokens. They are randomly generated values from the server-side that are passed along to the client. This makes performing CSRF attacks difficult for threat actors, as they would have to collect the valid token and add it to their request. Otherwise, the server will deny the client’s request. There are also SameSite cookies, which are security flags enabled to customize what cross-site requests are allowed. There’s a great Portswigger topic on the different attributes for SameSite cookies here if you’re interested. It is also possible to use the Referrer header in HTTP to prevent CSRF attacks. When a request is made by clicking a link or submitting a form, it is usually added to verify that the request came from the applications domain. Otherwise, it will often throw an error when it is modified.

That being said, there are many different variations to CSRF that are relevant in today’s applications as well. For more information on these attacks and their respective mitigations, I highly recommend checking out the OWASP Cross-Site Request Forgery Prevention Cheat sheet.

Warning – Please do not try these tactics and techniques on any domain without explicit permission from the domain owner. This information is solely for educational purposes, and Abricto Security is not responsible for any individuals who use these tactics and techniques in any unauthorized or malicious manner.