Research Academy
My account Customers About Blog Careers Legal Contact Resellers
The Burp Suite User Forum was discontinued on the 1st November 2024.

Burp Suite User Forum

For support requests, go to the Support Center. To discuss with other Burp users, head to our Discord page.

SUPPORT CENTER DISCORD

Testing with DVWA

Darwin | Last updated: Sep 06, 2016 06:20AM UTC

Using the DVWA app and attempting to brute force the front login as well as the login section of the app does not seem to function properly, even when using the brute force instructions on this website. Brute forcing the front page returns all 302 while attempting in the brute force section of the app returns all 200. For reference, I am manually entering the username and loading a password list with 25 options, one of which is the actual password.

Liam, PortSwigger Agent | Last updated: Sep 06, 2016 07:57AM UTC

Hi Darwin Thanks for your message. We've just reproduced the brute force attack on the login section of the app, the request with the correct username and password should have a different location; "Location: index.php" rather than "Location: login.php". Are you seeing the same difference in your response? In this situation you can use the Intruder > Options > Redirections settings to make Burp follow the redirection and then sort by length to find the successful login attempt. Please let us know if you need any further assistance.

Burp User | Last updated: Sep 07, 2016 01:32AM UTC

Thank you. That makes sense to me, however, when I try it with the redirect settings and get 2 responses, Response 1 indeed says "Location: login.php" while Response 2 states no location, but instead "Vary: Accept-Encoding". Also, when I sort by length, my results are all Status 200 with the following lengths: 1 options at 2108 2 options at 1958 17 options at 1908 including the baseline and the correct option 6 options at 1858

Liam, PortSwigger Agent | Last updated: Sep 07, 2016 08:01AM UTC

Hi Darwin When you successfully ogin to the application manually and capture the request / response in Burp Suite, do you see "index.php" in the Location header?

Burp User | Last updated: Sep 07, 2016 03:25PM UTC

Yes, the POST request is login.php, but after forwarding, the GET response is index.php

Liam, PortSwigger Agent | Last updated: Sep 07, 2016 03:34PM UTC

When you input admin : admin via the intruder, are you able to login to the application successfully? The response length should be 5219. We are using OWASP Broken Web Applications Project Version 1.2.

Burp User | Last updated: Sep 07, 2016 03:57PM UTC

I may try OWASP Broken Web Applications as I wonder if the issue is not related to the tool. Update: By lowering the security setting in DVWA, I was able to get a different result in burp. Now when I run the same attack, my result in the "Length" column is 5234 for all but the correct login. The result for the correct login is 5300. Looking back through my activity, it seems the DVWA security settings were set to their highest which was throwing redirects at me and who knows what else. When I realized this, I dropped the security setting to low, albeit maybe unreasonably easy, and things seem to be working. Note that even though I have redirects set to always in the intruder options, this low a security level does not employ any redirect. So is that the indication I should look for in a positive result? The longer "Length" vs the baseline and the rest? I was looking for any other indication, but did not find one.

Liam, PortSwigger Agent | Last updated: Sep 08, 2016 08:17AM UTC

A change in the length of a response can be a good indication that the attack requires further investigation. Often what you look for in such a situation is dependant on your knowledge of the application after manually crawling and testing.

Burp User | Last updated: Sep 08, 2016 03:38PM UTC