Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Extension API on edited HTTP Responses (IHttpListener, IProxyListener)

Federico | Last updated: Jan 13, 2022 02:33PM UTC

Hi! I'm experiencing an issue with edited HTTP Responses and Burp Suite extensions. I'm working on an application that signs HTTP requests and responses. I created a Burp Suite extension that resign request and responses, in order to be able to intercept those requests and responses and tamper them. Signatures are regenerated by my plugin and applied to requests/responses in order to avoid breaking the application. While this approach works correctly for HTTP Requests unfortunately, it does not work for edited responses. In fact if I trap a HTTP Response and edit it, the original response (and not the edited one) is passed to the extensions of type IHttpListener and IProxyListener. This behavior in my opinion is not correct because in order to let extensions be as much effective as possible they should work immediately before HTTP Requests and HTTP Responses leave Burp Suite. This way it is not possible to inspect or to tamper response modifications executed by the user with the Proxy tool and manual tampering on responses when encryption or signing mechanisms are in place become much more difficult. Thank you for your help! Federico

Hannah, PortSwigger Agent | Last updated: Jan 18, 2022 12:25PM UTC

Hi Federico Just to double-check, are you referring to intercepted messages that are edited and then passed through to an extension by either a proxy or HTTP listener? We recently made some changes in Burp related to returning the right request when using a context menu invocation on a request.

Federico | Last updated: Jan 18, 2022 01:26PM UTC

Hi Hannah, I'm referring only to HTTP RESPONSES (for the HTTP requests it works correctly) that are intercepted and edited by a user. In this particular situation the original response is passed to extensions of type IProxyListener and IHttpListener instead of the edited response. For the HTTP REQUESTS it works correctly and the edited request is passed to extensions. Consequently there is no way from an extension to log or to work on a edited response. It seems to me (but maybe I'm wrong) that times ago the edited response was passed to the extensions because I developed an extension to resign edited response for a particular assessment, but maybe I remember badly. Thank you for your help. Federico

Hannah, PortSwigger Agent | Last updated: Jan 18, 2022 02:50PM UTC

Hi Federico Sorry, I misread your original message. We'll do some further investigation into this to make sure this behavior is consistent across requests and responses, and try and find the version of Burp that this changed in.

Federico | Last updated: Jan 18, 2022 08:51PM UTC

Hi Hannah, thank you for your help! I'm waiting for updates! Federico

Hannah, PortSwigger Agent | Last updated: Feb 08, 2022 02:44PM UTC

Hi Federico I'm sorry for the long delay. We've looked into this, and this behavior is due to the fact that requests will go through Extender twice, both before and after the request is intercepted, whereas responses will only go through the extender one - before the response is intercepted. This behavior isn't going to change in the short term. However, we are currently working on a new Extender API. Once released, this new API will have more granular control over whether the request or response gets passed to the extension before or after the request is received in Burp. You can check out our upcoming plans on our roadmap here: https://portswigger.net/burp/pro/roadmap

Federico | Last updated: Feb 17, 2022 06:41PM UTC

Hi Hannah, Thank you for the response and for the details. Please consider allowing response modification in the extensions after the response has been intercepted in the new Extender API because it is a very important feature, especially when working with a client that implement strong security features (for example some mobile applications). Thank you for your help.

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.