Project Configuration Changes Aren't Picked Up During Current IHttpListener.processHttpMessage Call
(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.
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.
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.
Great, glad that works for you. We’ve no near-term plans for PAC support, so that would make for a nice extension.
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 . 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.
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.