Support Center

Burp Community

See what our users are saying about Burp Suite:

How do I?

New Post View All

Feature Requests

New Post View All

Burp Extensions

New Post View All

Bug Reports

New Post View All
Documentation

Burp Suite Documentation

Take a look at our Documentation section for full details about every Burp Suite tool, function and configuration option.

Full Documentation Contents Burp Projects
Suite Functions Burp Tools
Options Using Burp Suite
Extensibility

Burp Extender

Burp Extender lets you extend the functionality of Burp Suite in numerous ways.

Extensions can be written in Java, Python or Ruby.

API documentation Writing your first Burp Suite extension
Sample extensions View community discussions about Extensibility
Name is required.
Email address is required.
Invalid email address
Answer is required.
Exceeding max length of 5KB

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

Jon Passki 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.


Paul Johnston Sep 22, 2017 10:00AM UTC Support Center agent

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.


Jon Passki 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.

Paul Johnston Sep 22, 2017 03:17PM UTC Support Center agent

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.


Jon Passki 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

Paul Johnston Sep 25, 2017 09:03AM UTC Support Center agent

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.


Post Your public answer

Your name
Your email address
Answer