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

processProxyMessage doesn't take changes from processHttpMessage into account

Jerome | Last updated: Sep 26, 2016 08:43PM UTC

Hey guys, I am not sure if this is a bug or intended behavior but I wanted to let you know anyway. At work I recently made a small plugin that simply adds a custom header to outgoing requests by overriding processHttpMessage of IHttpListener. Obviously this doesn't show in the HTTP History tab but usually plugins like Logger++ log the request exactly as it hits the wire. In my particular case I could see the custom header for all tools except the proxy tool, even though I verified it using my server that the header was actually sent out. After a (long) while I decided to have a look at the requests using Flow, another popular logging plugin, and to my surprise this plugin actually was showing the custom header of my requests. I wanted to get to the bottom of this issue and it turns out that Logger++ logs requests for all tools except the proxy tool using processHttpMessage, but for the requests from the proxy tool it actually overrides processProxyMessage, whereas Flow simply uses processHttpMessage for all tools. I made a custom version of Logger++ that only uses processHttpMessage to confirm that processProxyMessage was indeed the culprit. As stated earlier, this could be intended behavior. Perhaps I am not adding my header in the intended place and I should override another function in such a scenario. I also posted this issue on the github page of Logger++ here: https://github.com/nccgroup/BurpSuiteLoggerPlusPlus/issues/22

PortSwigger Agent | Last updated: Sep 27, 2016 08:16AM UTC

You are right that IProxyListener is higher up the stack than IHttpListener, so changes made to a request by an IHttpListener happen after any IProxyListener has been called. For responses, it is the other way around, since the messages are processed straight off the wire by any IHttpListener, and later passed to any IProxyListener.

Burp User | Last updated: Sep 27, 2016 02:51PM UTC

Hey, So basically you do not consider this behavior a bug in Burp, but rather a bug in Logger++? Is there any general documentation on the order in which processing works? Besides the IProxyListener and the IHttpListener there is for example also the ISessionHandlingAction that can modify requests...

PortSwigger Agent | Last updated: Sep 27, 2016 02:54PM UTC

We don't consider it a bug in Burp. The two ways of interacting with messages via the Proxy have to be called one way around or the other. Either way around, you will see quirks if you make different assumptions. Also, the issue with Logger++ only arises due to the interplay with other extensions. Since multiple extensions can register listeners and make changes to messages in sequence, you may see quirks due to the order in which extensions are registered / invoked. The API documentation for the method on each interface vaguely implies that IHttpListener is lower level, but this isn't formally documented anywhere else.

Burp User | Last updated: Sep 28, 2016 07:14AM UTC

Ok, thanks for the information! "Also, the issue with Logger++ only arises due to the interplay with other extensions. Since multiple extensions can register listeners and make changes to messages in sequence, you may see quirks due to the order in which extensions are registered / invoked." I would like to make two suggestions here: 1) It would be useful if we could see the order in which extensions are invoked in the extender tab. Perhaps a screen with a listbox which shows the registered invoked functions and upon selection it shows the order of the extensions that invoke said function. 2) Perhaps it would be possible to allow extensions to specify a number which indicates when they want to be loaded. An extension like Logger++ could set this to a high number to ensure it is always invoked last, whereas a request/response modifying plugin could use a low number to ensure it is called first. Ideally the user should be able to overwrite this loading order in the Extender tab, for example to also set an order number on older extensions that don't set it in code. If needed I can post these suggestions in the feature request forum as well.

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