DVWA - CSRF
Starting the challenge
Refer to the post start DVWA with Docker to learn how to start DVWA.
I will mostly use Burp Suite to solve the challenges. To configure Burp suite refer to the post configure burp suite for DVWA.
Click on the CSRF button on the left menu to access the challenge.
Low Level
Understanding the application
We reach a page with a form to change our password.
If we try the form, a GET request is sent with our parameters and our password is changed.
GET /vulnerabilities/csrf/?password_new=test&password_conf=test&Change=Change HTTP/1.1
We can try by logging out and loggin in with our new password.
CSRF vulnerability
A Cross Site Request Forgery is a kind of vulnerability allowing an attacker to force users to perform actions without his knowledge.
To do so we can send a phishing email to the user with the following link http://localhost/dvwa/vulnerabilities/csrf/?password_new=hacker&password_conf=hacker&Change=Change.
When the user will click on the link, the password change will take place and the attacker will now have control of the user’s account.
The attacker could also use some Javascript to do the request automatically without requiring a user action.
Exploiting the vulnerability
To exploit this vulnerability we simulate an attack by creating a simple HTML file with the link :
<html xmlns="http://www.w3.org/1999/xhtml">
<body>
<div>
A holiday request was rejected.
Please click <a href="http://localhost/vulnerabilities/csrf/?password_new=hacker&password_conf=hacker&Change=Change">here</a> for more details.
</div>
</body>
</html>
When we open the HTML file in our browser, we simulate the malicious web site.
When we click on the link we are redirected to the password change page with the message password changed.
Vulnerable code
The problem here is that we do not verify that the user was intending to perform this action. A better design would be to ask for the previous password to prevent this attack.
Medium level
In the medium level the previous attack will not work.
When we analyse the differences between the request sent by a legitimate request and the one sent by our attack we can see that the legitimate request contains the referer header (not in our attack).
For our attack to work we will have to find a way to add this Referer option.
To do so we create a website http://mysite.com where we put our previously crafted malicious HTML page.
We suspect the server to check that the referer comes from the same site with a very simple regex or a contains function such as
if GET["REFERER"] contains GET["SERVER_NAME"] then {
To try our theory we host our code on http://mysite.com/localhost/index.html because the DVWA is running locally and the hostname is localhost.
When the user clicks on the page in the link the password is automatically changed ! It worked !
