Show Response in browser

[Merrick Clay]

I'm learning how to find and exploit vulnerabilities using PortSwigger's Academy, but because of the limitations of the free version of Burp, I'm trying to do it using OWASP ZAP, but I'm running into an issue with ZAP's functionality.

I'm working on the "2FA broken logic" lab, which requires me to brute force a 2FA code. Using Fuzzer, I brute force the code and get a 302 Found response once the right code is sent in a request. In order to complete the lab, I need to then send that response to the browser (which should lead me to the home page and log me in).

Here's my problem:
In Burp, I could right click the 302 response and select "Show response in browser". This would basically replicate the response in the browser, causing the browser to redirect me and log in. How can I do the same thing with ZAP?

Sending the request again is not an option, because the csrf is invalidated when the server receives a response with the right code.

Any help would be greatly appreciated.

Youtube video showing the functionality in Burp: https://youtu.be/btqm9-swsvU?t=266

[Simon Bennetts]

Hiya Merrick,

So we do have the ability to resend POST data in the browser but thats currently only via the HUD.

As you've just brute forced the code why cant you just submit it via the form where its asking for it?

There are other options, but that would seem to be the simplest one to try first :)

Do let us know how you get an and if you have any other problems using ZAP with PortSwiggers Academy - I've been meaning to try it for ages but just never had enough time ;)

Cheers,

Simon

[Merrick Clay]

Thanks for your input! The issue with resending a POST request or typing the code into the form in the browser is that I get a 400 error with this body: "Invalid CSRF token (session does not contain a CSRF token)".

[Simon Bennetts]

OK, so next thing to try - turn break on before submitting the token via the browser and then replacing the CSRF token with the one that was used in the request that returned the right token.

You have full control over the requests and responses send from/to the browser so yopu can change anything you like.

There will be a way to get this to work with ZAP - Burp isnt doing any 'magic' here :)

Make sure you understand when the CSRF token is being set and therefore what the server is expecting.

Its actually better to do it this way that relying on Burp to do things under the covers for you - you'll understand things much better if you have to do them all yourself :)

[Merrick Clay]

Thanks a lot for the help! It looks like I'll have to do more research into how csrf tokens are usually used.

Here's the solution in case anyone else runs into the problem:
- After you find out the 2FA code, the server will no longer accept any more requests with the csrf you have been using.
- Log back in to the website wit the provided credentials (user: wiener, pass: peter)
- Turn on "Set break on all requests and responses"
- Type in the 2FA code you found earlier and submit
- Change the verify header to "carlos"

- Click "Submit and continue to next breakpoint"
- (To finish the lab, go to your browser and click on My Account)

Why I think this works (may be wrong):
When the GET request is sent to the login2 endpoint, the server responds with the HTML for the 2FA webpage (which is where you enter the 4 digit code). On the webpage is a hidden input field for the csrf token (which has a value provided by the server in the response). This token gets invalidated when the correct 2FA code is sent to the server in a POST request on the login2 endpoint. Logging in again as wiener/peter sends a GET request to the login2 endpoint, providing you with a new, valid csrf token that you can then use to send in the 2FA code to log in to carlos' account.
I also imagine that instead of logging in again, I could have just resent the initial GET request (to login2) that was sent when I initially logged in, which would also provide me with a new csrf token to use (if i just Ctrl + F for "csrf" in the response and find the value), and then modified the csrf token in the request (from the Fuzzer) that initially found the right 2FA code and sent that.

Big thanks, Simon!

- Merrick