A Short HistoryBurp has supported extensions for years. Burp's extensibility began its live very simple, and has evolved gradually without any overall plan.
The existing API is fairly limited, and its main uses have been for:
- Changing HTTP messages on the fly
- Initiating some testing tasks (e.g. to automate crawling / scanning)
- WCF Binary Soap plugin, by GDS
- Deflate plugin, by GDS
- DSer plugin for JAVA serialized objects, by Attack & Defense Labs
- w3af plugin, by David Robert
Current LimitationsThe existing extensibility framework contains some significant limitations:
- You can only run one extension at a time.
- You can only load an extension at launch time, by modifying Burp's classpath.
- Only the Java language is natively supported.
- The processing of writing, compiling and loading an extension can be challenging for non-programmers.
- The API doesn't expose very much in many areas that would be extremely useful to be able to extend. For example: Burp's user interface, the Scanner, Intruder and session handling.
- Extensions are effectively bolt-ons, not properly integrated with Burp's internals.
- Buby (Ruby)
- Burp Suite Extended (Python)
- Hiccup (Python)
- Resty-Burp (REST / JSON)
The efforts that people were evidently going to, in an attempt to improve on what Burp itself offered, made me realize: it's time to fix Burp natively.
Objectives for New ExtensibilityThe overall objectives for the new extensibility framework are:
- Allow multiple extensions to run simultanously.
- Support dynamic loading and unloading of extensions at runtime.
- Support languages other than Java. In the initial release, Python is supported via the Jython interpreter.
- Provide a much, much richer API that allows extensions to really integrate with Burp's internals.
- Use a more future-proof API design, to allow easier enhancements in future.
- As far as possible, ensure backwards compatibility with legacy extensions.