Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Project Configuration Changes Aren't Picked Up During Current IHttpListener.processHttpMessage Call

Jon | Last updated: Sep 21, 2017 02:37PM UTC

(Burp: 1.7.27, OS: macOS 10.12, Java: 8) Given an IBurpExtender that registers an IHttpListener when the listener's IHttpListener.processHttpMessage is called, and the message is a request, it calls IBurpExtenderCallbacks.saveConfigAsJson("project_options.connections.upstream_proxy") to dump the current project-level configuration for Upstream proxies. If applicable, the current configuration is dynamically modified to include the current host (IHttpRequestResponse.getHttpService().getHost()) as a "destination_host" for an Upstream proxy server change. (It also sets "enabled" to true for the upstream proxy server.) The configuration it then saved via a call to IBurpExtenderCallbacks.loadConfigFromJson(). Expected result: after a project-level change for upstream proxies is updated (IBurpExtenderCallbacks.loadConfigFromJson) these changes should be picked up immediately after the IHttpListener.processHttpMessage (for a request message) completes. The current request then should use this new upstream proxy server configuration, since its host matches the destination host of the proxy server and the proxy server configuration is enabled. Actual result: the current request does not honor project-level configuration changes that are made during the IHttpListener.processHttpMessage call. However, subsequent requests to the same destination host do honor the newly added upstream proxy server and are correctly proxied.

PortSwigger Agent | Last updated: Sep 22, 2017 09:36AM UTC

Hi Jon, Thank for getting in touch. By the time processHttpMessage is called, Burp has already done most of the processing of the message. For example, the proxy has been identified, and proxy authentication will have been added (if applicable). So while this behavior is undesirable for you, it is consistent, and it's not something we're likely to change. If you hook the message earlier in processing, such as in IProxyListener or a Session Handling Action, you may be able to redirect the proxy. I have not tested this. You may be able to redirect the message to a proxy within processHttpMessage, by modifying the request to make it proxy style (i.e. full URL in first line) and using setHttpService to set the host/port of the proxy. Again I haven't tested this. I'm quite interested to know what your extension does? We may be able to suggest alternative approaches.

Burp User | Last updated: Sep 22, 2017 02:18PM UTC

Quick testing using an IProxyListener seems to do the trick. After the configuration is modified the request is correctly forwarded to the upstream proxy. I'm attempting to re-implement a PAC plugin that avoids the shenanigans the existing Jython plugin does. Instead of kicking up a web server and adding an additional (unneeded) hop, it'll just add the upstream proxy per-host based on the PAC results. The first step was to make sure that an added upstream proxy was honored, which now seems to be good. If PAC support is on your roadmap then please let me know and I'll stop coding :) No need to burn cycles on a soon-to-be dead-end project.

PortSwigger Agent | Last updated: Sep 22, 2017 02:25PM UTC

Hi Jon, Great, glad that works for you. We've no near-term plans for PAC support, so that would make for a nice extension. Does your extension process JavaScript in PAC files? You'll need to sandbox that carefully.

Burp User | Last updated: Sep 22, 2017 04:52PM UTC

Good to know re the roadmap. I'll document that the upstream library currently doesn't evaluate its ScriptEngine within a security manager of any type, as far as I can tell [1]. So if the user cannot trust the PAC source they shouldn't use the plugin. Otherwise, currently the PAC source is assumed to be trustworthy and not malicious. [1] https://github.com/MarkusBernhardt/proxy-vole/blob/master/src/main/java/com/github/markusbernhardt/proxy/selector/pac/JavaxPacScriptParser.java

PortSwigger Agent | Last updated: Sep 25, 2017 09:00AM UTC

Hi Jon, How does the extension get the PAC file? If it's explicitly provided by the user, the lack of sandboxing is non-critical. But if it uses WPAD, that is quite risky.

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