In this post, We demonstrated a scenario of exploiting CSRF vulnerability using DVWA vulnerable web application.
Cross site request forgery better known as CSRF exploits the website trust in the user. In CSRF, attackers forge requests to the website on behalf of the user making it look like it came from the user. Example application is password reset requests or changing password requests.
In CSRF, we would want to make a request to change a user’s password but making it as if the user made the request which is how CSRF works.
In order to exploit this vulnerability, we would need to grab the form code and use it in a page of our choosing.
Say we designed a page for software giveaways and we want visitors to visit the page and request a giveaway. Once they request a giveway, they unknowingly will send a password reset request to the website at which they have an account that happens to be our target.
CSRF vs. XSS
First, let’s clear up the confusion between CSRF and XSS.
- XSS (Cross-Site Scripting) is all about exploiting the trust a user has in a website. An attacker injects a malicious script into a trusted site, and when the user visits that site, the script runs in their browser.
- CSRF (Cross-Site Request Forgery), on the other hand, is about exploiting the trust a website has in a user. The attacker tricks a logged-in user into sending a malicious request to a website without them even knowing it.
How It’s Done
Here’s the playbook for a classic CSRF attack:
- Craft the Malicious Code: I start by creating some HTML code with a hidden script. This script is designed to perform an action that I want the victim to do, like changing their password on a vulnerable website.
- Lure the Victim: This is where social engineering comes in. I need to get the victim to visit my malicious webpage. I might create a fake website that I know they’d be interested in, like a giveaway for a popular VPN service.
- The Unwitting Accomplice: When the victim visits my site, the hidden script runs in the background. It sends a request to the vulnerable application, but since the victim is already logged in, the website thinks the request is legitimate. The victim has no idea they’ve just changed their password or performed some other action.
In my demonstration, I used a vulnerable application to show exactly how this works. I copied the JavaScript code for changing a password, embedded it in my own HTML page with a new password, and then created a fake giveaway page to lure the victim in. When they clicked the “send my order” button, they unknowingly changed their password on the other site.
How to Defend Against CSRF
So, how do we stop these kinds of attacks? The key is for web developers to use randomly generated tokens for every request a user makes.
Here’s how it works:
- When a user visits a site, the server generates a unique, random token and sends it to the user’s browser.
- Every time the user makes a request, that token is sent back to the server.
- The server checks to make sure the token is valid before it processes the request.
This way, even if an attacker tricks a user into sending a request, they won’t have the correct token, and the server will reject the request. It’s a simple but effective way to protect against CSRF and even some Man-in-the-Middle (MITM) attacks.
