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:
param=http://f294gchg2la...r9gf.burpcollaborator.net/
- 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.