Burp Collaborator Documentation

This section contains information about What Burp Collaborator is, How Burp Collaborator works, Security of data processed by Burp Collaborator, and Options for using Burp Collaborator.

What Is Burp Collaborator?

Burp Collaborator is an external service that Burp can use to help discover many kinds of vulnerabilities. For example:

  • Some vulnerabilities arise when an application interacts with external systems, based on supplied input. For example, out-of-band XSS can arise when an application fetches content from a URL specified in a request parameter, and returns that content unsanitized in its own response.
  • Some injection-based vulnerabilities can be detected using payloads that trigger an interaction with an external system when successful injection occurs. For example, some blind SQL injection vulnerabilities cannot be made to cause any difference in the content or timing of the application's responses, but they can be detected using payloads that cause an external interaction when injected into a SQL query.
  • Some service-specific vulnerabilities can be detected by submitting payloads targeting those services to the target application, and analyzing the details of the resulting interactions with a collaborating instance of that service. For example, mail header injection can be detected in this way.

When Burp Collaborator is being used, Burp sends payloads to the target application that are designed to cause interactions with the Collaborator server when certain vulnerabilities or behaviors occur. Burp periodically polls the Collaborator server to determine whether any of its payloads have triggered interactions. Burp may also control the responses that the Collaborator server returns when a target application interacts with it.

Burp Collaborator is currently only used by the Scanner tool. In future, other Burp tools will also make use of it.

How Burp Collaborator Works

Burp Collaborator runs as a single server that provides custom implementations of various network services:

  • It uses its own dedicated domain name, and the server is registered as the authoritative DNS server for this domain.
  • It provides a DNS service that answers any lookup on its registered domain (or subdomains) with its own IP address.
  • It provides an HTTP/HTTPS service, and uses a valid, CA-signed, wildcard SSL certificate for its domain name.
  • In future, bare-bones implementations of various other network services will be provided, such as SMTP and FTP.

A typical external service interaction can be detected via the Collaborator server as follows:

  • Burp sends a payload to the application containing a URL that uses a random subdomain of the Collaborator domain, for example:
  • Due to its programmed behavior (intended or otherwise), the application fetches the contents of the URL. To do this, it will first perform a DNS lookup on the random subdomain, and then perform an HTTP request.
  • The DNS lookup and the HTTP request are received by the Collaborator server. Both interactions contain the random data that Burp placed into the Collaborator subdomain.
  • Burp polls the Collaborator server and asks: "Did you receive any interactions for my payload?", and the Collaborator returns the interaction details.
  • Burp reports the external service interaction to the Burp user, including the full interaction messages that were captured by the server.

Further to this basic case, the Collaborator can play various other roles in the detection of vulnerabilities, for example:

  • The Collaborator server can return test payloads in its responses to the external interactions, enabling the detection of out-of-band versions of familiar issues like XSS and SQL injection.
  • Burp can submit injection-based payloads designed to trigger an external interaction when the injection is successful, enabling the detection of completely blind injection vulnerabilities.
  • The Collaborator server can notify Burp of deferred interactions that occur asynchronously following submission of the relevant in-band payload to the target. This enables the detection of various stored vulnerabilities, such as second-order SQL injection and blind XSS.

Security of Collaborator Data

Users may have legitimate concerns about the security of data that is processed by the Collaborator server, and the feature has been designed with a strong emphasis on the security of this data.

What Data Does the Collaborator Server Store?

In most cases, when a vulnerability is found, the Collaborator server will not receive enough information to identify the vulnerability. It does not see the HTTP request that was sent from Burp to the target application. In a typical case, it will record that an interaction was received from somewhere, including a random identifier that was generated by Burp. Occasionally, the Collaborator server will receive some application-specific data: for example, the contents of an email generated through a user registration form.

How is Retrieval of Collaborator Data Controlled?

The Collaborator functionality is designed so that only the instance of Burp that generated a given payload is able to retrieve the details of any interactions that result from that payload. This requirement is implemented as follows:

  • Each instance of Burp generates a securely random secret.
  • Each Collaborator-related payload that Burp sends to the target application includes a random identifier that is derived from a one-way hash (cryptographic checksum) of the secret.
  • Any resulting interactions with the Collaborator will include this identifier in the transmitted data (for example, in the subdomain of a DNS lookup, or the Host header of an HTTP request).
  • The secret is only ever sent by Burp to the Collaborator server, to poll for details of the resulting interactions. This is done using HTTPS, unless overridden in Burp's options.
  • When the Collaborator server receives a polling request, it performs the one-way hash of the submitted secret, and retrieves the details of any recorded interactions containing identifiers that are derived from that hash.
  • Hence, only the instance of Burp that generated the secret is able to retrieve the details of any interactions that are triggered by its payloads.

Further to this mechanism, the following precautions are also implemented in the Collaborator server to protect against unauthorized access to its data:

  • Details of interactions are stored in ephemeral process memory only.
  • No data of any kind is in recorded in any persistent form: for example, a database or log file.
  • Details of interactions are typically retrieved by Burp shortly after they occur, and are then discarded by the server.
  • Details of old interactions that have not been retrieved by Burp are discarded after a fixed interval.
  • There is no administrative function for viewing interaction details, only the retrieval mechanism already described.
  • The Collaborator server does not by design receive any data that could be used to identify any individual Burp user (such as an account name or license key).

Options for Using Burp Collaborator

Burp users can choose between the following three options for using Burp Collaborator:

  • Public Collaborator server - This is a server provided by PortSwigger that is shared between all Burp users who use it. If the public Collaborator server suffers from any service outage or degradation, then the efficacy of Collaborator-related functionality within Burp may be impaired. For this reason, PortSwigger makes no warranty about the availability or performance of this server.
  • Private Collaborator server - Anyone with a Burp Suite Professional license can run their own instance of the Collaborator server. To do this fully effectively, you will need a host server, a dedicated domain name, and a valid CA-signed wildcard SSL certificate. Private Collaborator servers without a suitable domain name or SSL certificate will be able to support some, but not all, of the Collaborator-related capabilities within Burp. You can protect your private Collaborator instance at the network layer: you can configure different network interfaces to receive interactions and answer polling requests, and you can apply whatever IP restrictions you want, given the locations of your targets and testers. The option to use a private Collaborator server is likely to appeal to penetration testing firms and in-house security teams. It can also enable individual testers to deploy a Collaborator instance when testing on private closed networks with no Internet access. See the documentation on deploying a private Collaborator server for more details.
  • No Collaborator server - You can configure Burp not to use any Collaborator server. With this option, none of the Collaborator-related capabilities within Burp will be available.

Note: The functionality of Burp Collaborator gives rise to issues that require careful consideration by users. Users should ensure that they fully understand the functionality and the alternative methods of utilization of Burp Collaborator, and have considered the consequences of utilization for themselves and their organization.

Within Burp, you can configure these settings within the Burp Collaborator server options.