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

Extender API for Custom OAST Servers

Wyatt | Last updated: Jul 11, 2022 08:21PM UTC

Collaborator is a great service that has recently had some competition via other OOB tooling in the last few years (interact.sh, canarytokens, etc.) It would be really handy for testing if PortSwigger could add (or update) an Extender API to allow developers to write their own Collaborator implementations. The IBurpCollaboratorClientContext and IBurpCollaboratorInteraction APIs do not expose enough functionality to perform this in a simplistic manner. In a generic sense, I'd expect the following interface functions: generate payload poll server for results stop listening for payload Currently only the generation of payloads and polling is available in the IBurpCollaboratorClientContext API. Similarly for the interactions, I'd expect a request and response property for any 'type' that is not DNS, not just HTTP. This would allow non-Collaborator services to implement any protocol they wish and send results through Burp. --- Why would this be a good idea? First off it would allow Burp users flexibility in using an OOB service of their choice. Collaborator supports DNS, HTTP(S), and SMTP(S). This is a great start, but it'd be even better to capture additional services. Developers could write their own OOB servers and detect any protocol they wish. Burp should just provide the generic interface for them to report it. Multiple OOB servers can be used to bypass WAFs and other detections. The burpcollaborator.net domain and now oastify.com are frequently added into DNS sinkholes of organizations so that the unique subdomains do not resolve. Security testers can set up their own Collaborator instance or other OOB server, but that could be subject to IP/domain blocks or a lack of supported protocols. Additional flexibility allows testers to not be limited to just Collaborator servers. Increasing the flexibility on the allowed OOB servers would take bandwidth off PortSwigger's open Collaborator services. If people can use any server they want, then this should reduce the reliance on the default servers. This could even lead to the Collaborator service being integrated into the Community version of BurpSuite (Scanner + Collaborator is the value add for Pro). It would be a huge benefit to use Burp's Collaborator client with other OOB servers. --- Considerations: A healthcheck on a Collaborator service checks for the default Collaborator ports. It may be worth adding to the custom interface for the extension to specify the available services and even an optional healthcheck method that defines a healthy response for each service. It'd be nice to include an additional "Burp Collaborator Server" option that allows an extension to specify the Collaborator implementation via drop-down (Similar to Extension-generated in Intruder). This way the extension could add an ITab or similar to define custom settings.

Hannah, PortSwigger Agent | Last updated: Jul 12, 2022 10:36AM UTC