DVWA: Damn Vulnerable Web Application CSRF Tutorial (Low Security)

 

"Disclaimer: The information provided in this article is intended for educational and research purposes only. It is not intended to promote or encourage any illegal or unethical activities. Always act responsibly and obtain proper consent before using any tools or techniques described in this article."

 

In this tutorial, we’ll be covering how to exploit a CSRF vulnerability on DVWA (Damn Vulnerable Web Application) on the lowest security setting.

CSRF stands for Cross-Site Request Forgery. Essentially, with this type of attack you ride a user's session and force them to take unwanted actions on a web application — providing they are currently authenticated with the application.

Because the lowest security setting has no security measures, this is a very simple attack. 

Let’s jump right in and take a look.

The first step, let's do a little recon on the password change form.  Select inspect element and go to the network section now Submit a password change and inspect the HTTP request.

Pretty straightforward. It's a GET request, and we can see the parameters sent along with the request.

So here is the attack scenario. I (a hacker with malicious intent) send the victim to my website. Here is what my website looks like:

Looks harmless enough. As far as the victim is concerned, it’s just text. But let's take a look under the hood.

Look closely at our img tag:

<img style="display:none"

        src="http://10.0.2.5/dvwa/vulnerabilities/csrf/?password_new=Oyeecoder&password_conf=Oyeecoder&Change=Change"

        alt="">

Instead of the src attribute pointing to an image asset (e.g a png or jpeg file), we’re pointing to the password change endpoint and changing the password to “Oyeecoder”.

So when the victim visits our attacker's website they are unaware that anything has happened. But if we look at the network requests: 

Our img tag made the browser send a GET request to change the password endpoint. And because the GET request came from the victim's browser, and the victim was already authenticated, it sent the PHPSESSID in an HTTP cookie.

So as far as the web application is concerned, the request came from an authenticated user.

Now you will be able to log in with the new password “OyeeCoder”.