Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Design of Active Scanner plugin vs InsertionPoints

Dirk | Last updated: May 15, 2015 10:52AM UTC

Hi all, I'm new to extending Burp and I wanted to add an active scanner plugin for XXE injection. Therefore I want it to take all post requests, change the content type to text/html and perform some xml entity queries for existing files. Problems I face : 1. I want this plugin to send one request url that supports POST. ( no matter how many parameters ) I tried to check for INS_PARAM_BODY, but that one does not get triggered when the body in the base request is empty. Dirty solution I guess I could (mis) check for the method and the INS_PARAM_URL insertion point, since that one seems to be called only once on each url. 2.So I'll define a custom insertion point. I want to create a custom insertion point that will only be used by some of my active scanner plugins. Now it appears to me that all the payloads are tried on all insertion points. This does seem like the logical approach , since than I could also test for other vulnerabilities where the payload is the full request body So my questions : 1. Is there a better way to create a scanner plugin that gets triggered only one time for each distinct url that was requested using POST ? 2. how to make sure that the insertion point in only used by active scanner plugins that explicitly defined them? Kind regards

PortSwigger Agent | Last updated: May 15, 2015 02:28PM UTC

Thanks for your questions. There isn't a neat way to do exactly what you want using Burp's native features, but there are some more-or-less hackish workarounds that might help with your two questions: 1. You could check for an insertion point that (normally) only exists once per request, such as INS_PARAM_NAME_URL, and trigger your custom check logic based on that. Or, if you persue the custom insertion point option, you could check for INS_EXTENSION_PROVIDED, and use that to trigger your check logic. 2. You can't elegantly stop Burp's native scan checks from using your custom insertion point. A horrible hack would be to look at the payload passed to your insertion point, recognize if this is one of your own payloads, and not a Burp native one, and throw RuntimeException if the latter. Burp will alert you about the exception, but will carry on scanning and skip that insertion point. Very nasty, but it might do the job as a one-off solution.

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.