SeanBurnsUK
commented
1 year ago 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
Hannah-PortSwigger
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
initializemethod. 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: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.