Burp Suite User Forum

Extension API processHttpMessage does not honor set* methods

floyd | Last updated: Mar 24, 2020 03:43PM UTC

Hi there, At least version 2020.2.1 broke the processHttpMessage extender API. You can try to use the "Add Custom Header" extension from BApp to see the issue. It is not setting a header. To confirm it's not that extension I coded my own extension to reproduce, see below. According to the "processHttpMessage" documentation on https://portswigger.net/burp/extender/api/burp/IHttpListener.html it states "messageInfo [...] Extensions can call the setter methods on this object to update the current message and so modify Burp's behavior". Simply put: Even when setRequest is called, Burp won't change the request as seen in the Proxy tab, there won't be a header "FooBar: BazBar" in the request. Please please please create UnitTests for the API. These kind of things are painful for extension developers. Python extension ---------------- from burp import IBurpExtender from burp import IHttpListener from burp import IBurpExtenderCallbacks from burp import IHttpRequestResponse from burp import IHttpService class BurpExtender(IBurpExtender, IHttpListener): def registerExtenderCallbacks(self, callbacks): self._callbacks = callbacks self._helpers = callbacks.getHelpers() callbacks.setExtensionName("Stop breaking the Extender API") callbacks.registerHttpListener(self) print("Stop breaking the Extender API!") def processHttpMessage(self, toolFlag, messageIsRequest, messageInfo): if messageIsRequest: if toolFlag == IBurpExtenderCallbacks.TOOL_PROXY: self.add_request_header("FooBar: BazBar", messageInfo) print "Set request:", FloydsHelpers.jb2ps(messageInfo.getRequest()) def add_request_header(self, header_line, messageInfo): req = FloydsHelpers.jb2ps(messageInfo.getRequest()) splitted = req.split("\r\n") new = [splitted[0], header_line] new.extend(splitted[1:]) new_req = "\r\n".join(new) messageInfo.setRequest(FloydsHelpers.ps2jb(new_req)) class FloydsHelpers(object): @staticmethod def jb2ps(arr): """ Turns Java byte arrays into Python str :param arr: [65, 65, 65] :return: 'AAA' """ return ''.join(map(lambda x: chr(x % 256), arr)) @staticmethod def ps2jb(arr): """ Turns Python str into Java byte arrays :param arr: 'AAA' :return: [65, 65, 65] """ return [ord(x) if ord(x) < 128 else ord(x) - 256 for x in arr]

Hannah, PortSwigger Agent | Last updated: Mar 25, 2020 11:51AM UTC

Hi Thank you for providing a test extension. Whilst the extension-edited request does not appear in the Proxy History table (instead it is displayed as the original), the request is still edited. You can check this by installing a third-party monitoring extension like Flow or Logger++. With regards to "Add custom header", if you monitor the outgoing requests through Flow or Logger++, is the request edited? The order of extensions in Burp does matter, so if you change the order, does that fix the behavior? I can put a feature request in for extension-edited requests to be displayed in the proxy history, if you would like? However, I will be unable to provide an ETA for when this feature would be implemented.

floyd | Last updated: Mar 25, 2020 04:48PM UTC

Hi Hannah, I checked, and indeed the request is really edited (I can see it in Wireshark when going to a non-TLS HTTP site, I use http://example.org). However, I wasn't seeing it in Logger++. So I checked and actually I can see it in Flow, but not in Logger++, no matter what I do. I'm aware that the order of extension matters. Flow does not care if it is the first in the list or the last, it always works and shows the header and correct request. However, Logger++ does not work, no matter which one it is in the list. I even tried all combinations of unloading and reloading the extensions, but the header will simply not show up in Logger++, which is super strange. I checked, Logger++ wasn't updated since 2018, so if you have any idea what else it could be I would appreciate that. Does Logger++ work for you? A feature request for extension-edited request being shown in the proxy history would be nice, thank you.

floyd | Last updated: Mar 25, 2020 05:56PM UTC

Sorry, nevermind, it was this very quirky edge-case described here: https://github.com/nccgroup/BurpSuiteLoggerPlusPlus/issues/42 . You can regard this issue as closed. Lesson learned: Debugging becomes very hard when your debugging tools (Logger++) fail :)

Hannah, PortSwigger Agent | Last updated: Mar 26, 2020 08:30AM UTC

Hi, I've made the feature request to be reviewed further by our development team. We have a large backlog of feature requests, so I am not able to provide an ETA for when this may be implemented. I'm glad your issue is resolved. If there's anything else we can help with then please let me know.

You need to Log in to post a reply. Or register here, for free.