Name is required.
Email address is required.
Invalid email address
Answer is required.
Exceeding max length of 5KB

Is it possible to get the request that originated a response from a MessageEditorTab?

pwntester May 07, 2015 11:19AM UTC


Is it possible to get the request that originated a response from a MessageEditorTab?

Im only adding the tab for the responses, I want to search a log file based on a request header and paste the log entry in the response message editor tab.

I can see you can access the response (content) from there but not the request, is anyway to do this?

My current approach is to add the request header to the response using a Servlet filter so that I can get the header from the response (since I cant access the request) but I would like to avoid having to deploy this filter on every application under test


Dafydd Stuttard May 07, 2015 03:13PM UTC Support Center agent

Yes, you can do this. When Burp adds your custom tab to an HTTP message editor, it will call into your IMessageEditorTabFactory to obtain a new instance of your IMessageEditorTab. At this point, it also passes to your code an IMessageEditorController object, which is tied to the instance of your tab that you create. Your tab can query the IMessageEditorController to determine the associated request when showing a response message, and vice versa. See:

pwntester May 07, 2015 03:46PM UTC
Cool, thanks!

The only problem is that the request instance I get with IMessageEditorController.getRequest() is not the one that was actually sent since Im using IHttpListener.processHttpMessage() to add a couple of custom headers and I get the original request, not the modified one.

I can create a map containing a hash or the original request and the new headers within processHttpMessage and then use it in the tab with the request returned by getRequest() but seems hacky to me. Is there a way to get the actual request that gets sent?


Dafydd Stuttard May 11, 2015 10:37AM UTC Support Center agent

The IMessageEditorController API is all about interacting with an HTTP message editor within Burp’s UI, and the getRequest/getResponse methods return the messages that are displayed in the UI.

What you’ve identified is the fact that extensions can use an IHttpListener to modify messages on the fly at the point they are written to / read from the wire. These modifications aren’t propagated back to the invoking tool, and so aren’t shown in the relevant UI. The reason for this is that Burp’s tools generally need to operate on the requests that they generated, before any modifications by extensions – for example, the Scanner needs to apply highlights to payloads in requests, and it wouldn’t be able to do this correctly if requests were modified in arbitrary ways after the payloads had been inserted.

Agreed, your workaround is a bit messy, but it might be necessary if you really need to do this. Alternatively, if the modifications made by your IHttpListener (adding headers etc) are deterministic, then you could simply reapply those to the request that is shown in the UI, to derive the one that was actually sent.

Post Your public answer

Your name
Your email address