Extra requests when "Stop Drop Requests" is enabled for non-Proxy traffic about auth_analyzer HOT 10 CLOSED

Your expectation is correct if you have one session set. Could it be that you have more than one session set?

Furthermore, I assume that you sent a request to the repeater which has no response yet (means the IHttpRequestResponse object has no response message). For this reason the Auth Analyzer displays "No response to show" at the original response...

from auth_analyzer.

"No response to show": got it, thanks! Extra requests: I went through my tests again, I confirm the outcome with a single session. Details below...

Here we have two lines in the extension tab, but I think we should have only one (the one related to the ReproBug session). Is my understanding correct?

That's imo the weirdest part (taken from Logger++ logs):

• why is the Repeater request not blocked?
• why is the extension sending two requests for a single session?

from auth_analyzer.

Another point: are these two way of doing it equivalent? If not, what are the expected differences?

• call "Repeat request" from the extension's contextual menu
• send from Repeater, with "Only proxy traffic" disabled and "Drop requests" enabled

from auth_analyzer.

"why is the Repeater request not blocked?": Drop Original Request drops only proxy requests. You can use it to test idempotent operations while navigating through a web app.
"why is the extension sending two requests for a single session?": Indeed, this is weird. I assume another extension is also repeating the same request and therefore the auth analyzer is invoked twice. Pleace disable all other extensions and retry.
Repeat request from context menu repeats the selected request for all defined sessions but no the original one. Hope that helps...

from auth_analyzer.

Thanks for all these responses, I start to get it!

If the following points are already documented somewhere, I'm sorry but I missed it. If not, maybe adding them to the README?

• "Drop Original Request" only applies to Proxy
• "Repeat request" repeats for all defined sessions, except the original one

Regarding the "two requests for a single session", I retried after disabling all macros, all session handling rules and all extensions except AuthAnalyzer. Same outcome. I added a sniffer just to be sure, there's indeed 3 requests sent. Did you manage to reproduce this behavior?

Tested under Linux with Burp Suite Pro 2021.8.1-9276 and AuthAnalyzer 1.1.7 (from BappStore)

from auth_analyzer.

I am not able to reproduce the behaviour. The request can only be processed twice if the processHttpMessage method of the HttpListener class is invoked twice. This method is invoked by the Burp Suite. Looking at the Logger+ Output shows that a request of an extension, followed by the repeater request and after that another request sent by an extension. How is it possible that the first request is sent by the extension if your repeater request is not sent yet?

from auth_analyzer.

How is it possible that the first request is sent by the extension if your repeater request is not sent yet? Good question ;-) Given this order may change, I'd bet on a time/display glitch in Logger++ (maybe that the response was received before, despite the request being sent after).

I'll keep digging!!

from auth_analyzer.

Okay, got it:
You switched to "Drop Original Requests" and therefore the Auth Analyzer repeats the Request if the IHttpRequestResponse has no response yet. However, since only Proxy requests are really dropped, the auth analyzer is invoked a second time as soon as the response is received.
The following change within HttpListener will fix this issue:
if(config.isRunning() && (!messageIsRequest || (messageIsRequest && config.isDropOriginal() && toolFlag == IBurpExtenderCallbacks.TOOL_PROXY)))

Thanks for reporting it

from auth_analyzer.

[...] the auth analyzer is invoked a second time [...] -> Good catch! Glad my analysis was correct. Looking forward to testing v.1.1.8 ;-)

[...] The following change within HttpListener will fix this issue[...] -> Thanks! For reference, here's a permalink to the relevant line

from auth_analyzer.

Fixed with the last release. Thanks for reporting ngregoire.

from auth_analyzer.