DerbyCon · Louisville, KY · 2017 · 20 min

Burp is the tool most of us live in for web testing, but a lot of people never touch the Extender tab. This talk was my pitch for changing that: if you keep doing the same check by hand, Burp will let you write it once and have the scanner do it for you.

What I covered

Where extensions come from. The BApp Store, what the Pro-only flag means, and how to load your own JAR or script through Extender (and where its output and errors show up when it doesn’t work).
Language choices. Java, Python through Jython, or Ruby through JRuby. Same API either way.
The Extender API. You can read and modify requests and responses, hook into the built-in tools, add your own tabs and context-menu items, and persist settings between sessions.
The skeleton. A BurpExtender class implementing IBurpExtender, with registerExtenderCallbacks as the entry point. For scanner work you also implement IScannerCheck: doPassiveScan, doActiveScan and consolidateDuplicateIssues.
Passive checks. They run in the background on traffic Burp has already seen and never send anything. You pick what to look at (headers, cookies, parameters) and report issues; duplicates with the same name get consolidated.
Active checks. Burp hands you a base request and an insertion point (query string, form field, cookie, header). You build a request with your payload, send it, and decide from the response whether it’s a finding.
A live demo of a sample extension doing both, run against a target on my laptop.

One gotcha that bit me: issue markers have to be added in the order their offsets appear in the response, or the highlighting goes sideways.

The API has grown a lot since 2017 (PortSwigger has since added the Montoya API), but the passive/active check model in this talk is still how scanner extensions work.

View the slides · All talks

What I covered#

What I covered