Research Academy
My account Customers About Blog Careers Legal Contact Resellers
The Burp Suite User Forum was discontinued on the 1st November 2024.

Burp Suite User Forum

For support requests, go to the Support Center. To discuss with other Burp users, head to our Discord page.

SUPPORT CENTER DISCORD

Need more info on GUI controls, configuration storing and parameters' parsing for my Burp extension

Alex | Last updated: Jan 25, 2015 11:10AM UTC

Greetings. I'm trying to compose my first Burp extension, and stumbled upon some problems I haven't been able to resolve with google's help. I have to mention that I'm not so skillfull programmer, also, so I'm in search for simplest solution possible to complete the task (this extension is actually a meaningfull project, I need it asap to do my daily work). I use python as a programming language because of its simplicity. The extension itself will automate insertions of different payloads into parameters transmited in POST requests. At the very least it will check is intercepted POST request contains parameters from some list provided via configuration file, and if it is, than insert some payload into them (different modes of insertion are suggested). The basic functionality is already at work, but I'm seeking the way to improve its usability and applicability further. For that I need additional knowledge in this 3 general directions: 1) I need to be able to program some rich GUI features for my tool, and failed to find a good explanation how to do so. Examples on Burp's website mention only standard gui elements - edtior, log panel etc. But I need to know how to add some buttons which will reset specific of variables in my code, as well as input fields (including multiline ones), file loading/saving functionality (with ability to traverse local directories while searching for file), checkboxes and drop-down lists, and some pop-up panels with all the elements mentioned before (I would like that my tool be able to parse POST parameters in real-time(atm I doing this beforehand, manually, and sumbit them in conf. file) and present them to user in some pop-up window where he can select with checkboxes those which will receive the payload) 2) I would like that my tool be able to store its configuration data (including long lists of parameters, payloads and target urls) in some consistent manner, by using the same approach other extensions and native Burp's modules use. I.e., I would like to get rid of my custom configuration files (only allow users to feed tool with input from files, but after that all this input should be stored the same way Burp stores all its other configuration data, in some its internal(?) storage). How can I do that? 3) Currently the tool is able to handle parameters, presented as simple string with "&" as delimiter, as well as those transmited in multipart/form-data format. I simply use some simple regexps to search for signatures like (rougly) "\&[^&]*\=" or "Content-Disposition[^\n]*\n\r\n\r", i.e. it's handled by code, written by myself. I would rather like to use some respected and well-established parameters' parser instead, as I doubt my code applicability for all possible (non-standard?) causes, and I need it to be able to handle much broader selection of possible protocl using POST requests (json, to name one). Is there such kind of a thing one could handle with python code?

PortSwigger Agent | Last updated: Jan 26, 2015 10:06AM UTC

1. You can use the callbacks API addSuiteTab() to add your own Java UI component as a new top-level tab in Burp. You can then do anything you like within that tab in terms of providing the user with input fields, buttons, etc. An introductory book/tutorial on Swing will help you if you're new to Java's UI. If your extension is going to have a lot of UI, it might be easier to write it directly in Java, rather than translating everything from Python. 2. You can use the callbacks APIs saveExtensionSetting() and loadExtensionSetting() to store your configs as name/value pairs, in the same form that Burp's own settings are stored. Each extension's settings go into their own sub-hive in the Java preferences store. 3. You can use the API IExtensionHelpers.analyzeRequest() to use Burp's internal parameter parser to do your work. Hope that helps.

Burp User | Last updated: Mar 04, 2015 10:14PM UTC

Dafydd Stuttard, thank you very much for your answer. I totally forgot for some time that I left a question here. Yes, your answer was very helpfull, aside from this one: >3. You can use the API IExtensionHelpers.analyzeRequest() to use Burp’s internal parameter parser to do your work. Yes, I know about this feature, but logic of my extension involves not only parsing for parameters, but assigning them new values afterwards, and reconstructing the initial request while preserving exact order and number of all those parameters. I found how to do parse them with IExtensionHelpers.analyzeRequest(), but I didn't get how to easily reassemble them again into POST request ready to be forwarded over the wire. So I resorted to aquiring plain-text representation of request's body and searching for correct injection points utilizing regular expressions, as a workaround. This way I can insert my payload string into the request body string in several simple operations and then immidiately reassemble and send this request out. Is there a better way to achieve the same result? Moreover, I've got one more question. Do callback functions one is using during extension's creation process calls synchronously, or not? I mean, lets imagine callback function processProxyMessage() was called and started processing POST request, what is taking some time. While it's busy with this, new POST request arrives at the Burp proxy. What will happen then? Will new request will be held in buffer waiting untill my extension is done with the previous one? And if it's so, is there some time-out in case it's taking too much time for extension to process previous message, after which new message will be simply send to its destination, without getting into my extension? This matter is bothering me because I use a complex set of state flags stored in global variables, modified in different spots throghout the source code. My extension won't be able to produce correct results in case some other request can intervene with processing of previous one.

PortSwigger Agent | Last updated: Mar 05, 2015 02:42PM UTC