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

Ffuf + Burp Suite to brute-force login with CSRF token

Matheos | Last updated: Jan 28, 2021 12:49PM UTC

Apologies for this post being copied from my original one at SO, though I did not know of this forum when I made that post, and I don't seem to get any help on the matter overthere. Unfortunately I don't seem to be able to add screenshots on here, so if you need clarifications, they can be viewed here: https://stackoverflow.com/questions/65888814/ffuf-burp-suite-to-brute-force-login-with-csrf-token I want to brute-force the login page of "Damn Vulnerable Web App (DVWA)". I am hosting the DVWA myself. I am making use of Burp Suite Community edition along side Ffuf, by redirecting Ffuf traffic through Burp Suite proxy. I do this to handle session cookies and such easily (Burp suite does it for me). I am trying to set up a Burp Suite macro which fetches the latest CSRF token from the login page prior to brute forcing the POST request for logging in. I can see in the session tracer of Burp Suite the macro is run and the login page is fetched and the CSRF token is found and modified in my POST request that originates from Ffuf. The problem is that in the proxy HTTP history tab I only see my original POST requests containing the same static CSRF token that was in the original HTTP request I captured (compare to the one in first picture which got modified, which I am using as a template for my fuzzing). Why can't I see the requests made by the macro in the history? Does this mean I cannot get the feedback back to Ffuf to determine the difference between successful and failed login? All attempts return the same 302 status from the POST login (even successful ones I tried manually). They are also the same length and everything. The difference I expect is the redirect page, but as the history tab only shows me sending the invalid CSRF token I assume that is what is given back to Ffuf which, even with the -r flag (redirect) gives same content for all attempts.

Uthman, PortSwigger Agent | Last updated: Jan 28, 2021 01:51PM UTC

Hi Matheos, The HTTP History is only for traffic passing directly through the proxy from e.g. your configured browser (or the embedded one). You can see the history of the macro requests by either opening the sessions tracer or installing an extension like Flow or Logger++ from the BApp Store. Can you give this a try and let us know if that meets your requirements?

Matheos | Last updated: Feb 03, 2021 01:45PM UTC

Hi Uthman and thanks for your response. With the information you gave me it now makes sense. My problem still persists, but not because of burp suite, rather than I don't understand how to differ failed login attempt POST request responses from successful ones in my fuzzer FFUF... They all return 302 and all are same length and same headers. I was hoping the redirect page would differ, which it does when I perform a successful login manually, but when emulating the login using a raw POST request, only the initial login page is fetched as a redirect, no matter what password or whatnot has been given. My burp macro now performs a fetch before the POST, which updates the PHPSESSID and also the user_token, making sure they are always valid. Not sure where I go from here

Uthman, PortSwigger Agent | Last updated: Feb 03, 2021 01:50PM UTC