API Suggestions

[Static-Flow]

First off congrats on starting a re-write, as one of the more prolific extension creators I'm happy to see improvements being made!

Below is a list of changes I'd like to see made in the new Montoya API:

Extension wide access to the the Montoya APIs through a Singleton:

Like the previous API version, the Montoya API methods are handed to extensions through a parameter in the initialize method. This works but requires passing that reference around to every class you want to use it in or wrapping it in a custom Singleton which is what I normally do. By converting the Montoya API class to a Singleton, any custom extension code can access them with a simple:

MontoyaAPI.getInstance().{YOUR_METHOD_HERE}

Getters/Setters for everything:

This is mentioned in #10 but I wanted to reiterate it. There is a lot of functionality that is hard to make because there is no way to access the data. For instance, my extension for saving Intruder tabs: SaveIntruderTabs requires walking the Swing UI tree to find the Intruder tab component and extract the data from it.
This would all be much simpler with a MontoyaApi.getInstance().Intruder().GetIntruderTabs() method. The same is true for Repeater.

More Swing Component Access

This has been another sticking point when trying to build extensions like this: RepeaterSearch which adds a search bar for searching all repeater tabs for a string. To do this effectively I've had to make a library BurpGuiLibrary that makes crawling the Swing tree of Burp Suite in search of a component less painful. This library would not be necessary if there was a MontoyaApi.getInstance().Repeater().getComponent() method. Likewise for .Intruder() , .Sitemap() and so on for easy GUI manipulation.

Access to the Setting Menu

Giving extensions access to the Settings could be useful when building extensions that want to add on the fly session handling rules/macros/etc. Additionally, and this is more of a subset of the above recommendation, a MontoyaApi.getInstance().Settings().AddMenu(String Name, Component menu) method for adding a custom Settings menu would allow extensions to move away from needing a suite tab to show settings.

Persist Project Specific Extension Settings

I believe this was mentioned in the blogpost asking for suggestions but I wanted to reiterate it that giving extensions a way of saving state specific to a project would be helpful! SaveIntruderTabs requires saving the tabs outside the project because there's no way to save arbitrary data to a project file.

[SeanBurnsUK]

Thanks for your feedback.

The project persistence feature is coming very soon. So keep an eye out for that.
The settings menu is a good idea and I will create a ticket for our roadmap.

As for "getters/setters for everything", we don't really like the idea of exposing the swing hierarchy / UI elements in the API. We are continuously updating and improving the UI of burp, and we don't want to tie that to the extensions. For example repeater tabs could be replaced with a tree or some other system to improve UX.
We do have plans to expose the data of the tools though, which should serve a similar function (e.g. api.repeater().requesters().get(0).name() for your search)

The singleton idea, it would require a large change to our class loading strategy (each extension gets its own copy of the api which may contain state [registered listeners etc]). For us to set a static field via reflection would require each extension to include a copy of the MontoyaApi class using our currently class loading strategy. We can fix this but we think that adding other features (Like the other ones you mention) provide more value over this as extension developers have a easy way to setup there own singleton.

[Static-Flow]

Saw the new persistence APIs which is great to see! I had another request for API functionality that doesn't yet exist.

I was looking into making an extension for providing enhanced scope beyond just the binary in scope/out of scope that is built into Burp. The plan to make this work was to build a HTTPListener to monitor all outgoing requests and deny them granularly based on a set of user supplied rules. This would allow things like "leave domain dev.foo.com in scope but deny crawling requests" or "leave domain admin.foo.com in scope but deny active scan requests above "Medium Active"

This isn't really possible due to there being very little information to go on from HttpRequestToBeSent about what generated the request. I can see from toolSource() that it's from the Scanner but that's it.

It would be great if that class could expose a "source" field that could be populated with info about the Scan that generated it and also what issue like "Extension driven" or "SQL injection".

[Hannah-PortSwigger]

Thanks for the feedback. We have an ongoing feature request to include various metadata with requests in Burp, to which I've added your +1.