DVWA - CSRF

Information

• How to install dvwa on Kali.
• Official GitHub repository.

The DVWA server itself contains instructions about almost everything.

Damn Vulnerable Web Application (DVWA) is a PHP/MySQL web application that is damn vulnerable. Its main goal is to be an aid for security professionals to test their skills and tools in a legal environment, help web developers better understand the processes of securing web applications and to aid both students & teachers to learn about web application security in a controlled class room environment.

The aim of DVWA is to practice some of the most common web vulnerabilities, with various levels of difficultly, with a simple straightforward interface.

The DVWA server has 4 different security levels which can be set as seen below:

• Low: This security level is completely vulnerable and has no security measures at all. It’s use is to be as an example of how web application vulnerabilities manifest through bad coding practices and to serve as a platform to teach or learn basic exploitation techniques.
• Medium: This setting is mainly to give an example to the user of bad security practices, where the developer has tried but failed to secure an application. It also acts as a challenge to users to refine their exploitation techniques.
• High: This option is an extension to the medium difficulty, with a mixture of harder or alternative bad practices to attempt to secure the code. The vulnerability may not allow the same extent of the exploitation, similar in various Capture The Flags (CTFs) competitions.
• Impossible: This level should be secure against all vulnerabilities. It is used to compare the vulnerable source code to the secure source code.

Cross Site Request Forgery (CSRF)

CSRF is an attack that forces an end user to execute unwanted actions on a web application in which they are currently authenticated. With a little help of social engineering (such as sending a link via email/chat), an attacker may force the users of a web application to execute actions of the attacker’s choosing.

A successful CSRF exploit can compromise end user data and operation in case of normal user. If the targeted end user is the administrator account, this can compromise the entire web application.

Source video walkthrough.

Security: Low

There are no measures in place to protect against this attack. This means a link can be crafted to achieve a certain action (in this case, change the current users password). Then with some basic social engineering, have the target click the link (or just visit a certain page), to trigger the action.

Let’s start by confirming that we have some valid credentials for the user admin:

If we try to change some random password and intercept the traffic with Burp Suite, we can notice the following results:

The GET request has three parameteres: password_new, password_conf, and Change.

This information could be combined with social engineering techniques and change the password of the user admin without him realising it. For instance, if that user was already authenticated on the site:

1. We could create a link with those params set: http://127.0.0.1:42001/vulnerabilities/csrf/?password_new=test123&password_conf=test123&Change=Change
2. Obfuscate it: Click here to win an iPhone!
3. Send the link via an email to the admin user.

If the user clicks the link, the password will change and we can take over the entire web application:

We should be able to confirm the changes by testing the test:test credentials, but it does not work. The lab itself has this note: Browsers are starting to default to setting the SameSite cookie flag to Lax, and in doing so are killing off some types of CSRF attacks. When they have completed their mission, this lab will not work as originally expected.

Security: Medium

For the medium level challenge, there is a check to see where the last requested page came from. The developer believes if it matches the current domain, it must of come from the web application so it can be trusted. It may be required to link in multiple vulnerabilities to exploit this vector, such as reflective XSS.

Not work as intended.

Security: High

In the high level, the developer has added an “anti Cross-Site Request Forgery (CSRF) token”. In order by bypass this protection method, another vulnerability will be required.

At this level, the site will also accept a change password request as a JSON object in the following format:

{“password_new”:”a”,”password_conf”:”a”,”Change”:1}

When done this way, the CSRF token must be passed as a header named user-token.

Security: Impossible

At this level, the site requires the user to give their current password as well as the new password. As the attacker does not know this, the site is protected against CSRF style attacks.