DVWA CSRF Tutorial (Low Security)

Danny Beton
3 min readJul 20, 2016

--

*** Nothing contained in this article is intended to teach or encourage the use of security tools or methodologies for illegal or unethical purposes. Always act in a responsible manner. Make sure you have written permission from the proper individuals before you use any of the tools or techniques described here.

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 users 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.

First step, lets do a little recon on the password change form. Submit a password change and inspect the HTTP request.

Pretty straight forward. Its 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 lets take a look under the hood.

Look closely at our img tag:

<img style="display:none" src="http://192.168.0.11/dvwa/vulnerabilities/csrf/?password_new=pwned&password_conf=pwned&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 “pwned”.

So when the victim visits our attackers 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 victims browser, and the victim was already authenticated, it sent the PHPSESSID in a HTTP cookie.

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

Now you will be able to login with the new password “pwned”.

Happy hacking,

Danny

--

--