Testing for asynchronous vulnerabilities using the Burp Collaborator client
Last updated: August 25, 2022
Read time: 3 Minutes
In this tutorial, you will learn how to use the Burp Collaborator client to test whether you can induce a target site to make asynchronous, out-of-band requests to an arbitrary server that could potentially be controlled by an attacker.
The Burp Collaborator server provides custom implementations of various network services. The Burp Collaborator client enables you to take advantage of these during manual testing by providing you with "Collaborator payloads". These are simply the names of one or more subdomains of the Collaborator server's domains, for example:
We periodically add new domain names for the public Collaborator server to reduce the chance of WAF blacklisting resulting in false negatives. By default, the Burp Collaborator client always uses the newest public Collaborator domain that was available when your current version of Burp Suite Professional was released. At the moment, this will either be
To ensure that you experience the full benefits of Burp Collaborator, please make sure that the machine running the Burp Collaborator client can access both of these domains on ports 80 and 443.
In addition, the target application must be able to access
*.oastify.com on ports 80 and 443.
You can try to inject these subdomain names into the application, then poll the Collaborator server for attempted interactions with them.
Step 1: Access the lab
Open Burp's browser, and use it to access the following URL:
Click Access the lab and log in to your PortSwigger account if prompted.
Step 2: Identify a suitable input to test
You first need to identify an input that is used by the application to generate a secondary, asynchronous request. For the sake of this tutorial, let's assume you already know that this lab fetches the URL specified in the
Referer header when you load one of its product pages.
Visit a product page and send the resulting
GET /product?productId=X request to Burp Repeater.
Step 3: Open the Burp Collaborator client
To open a new Burp Collaborator client window, from the Burp menu, select Burp Collaborator client.
Step 4: Getting a payload URL
In the Collaborator client window, click Copy to clipboard.
This provides a Collaborator payload and copies it to your clipboard.
You need to keep the Burp Collaborator client window open while using a given payload. Each Collaborator client window is only able to poll for interactions with payloads that it generated, and there is no way to reopen a window if you close it.
Step 5: Inject your Collaborator payload into a request
In Repeater, replace the URL in the
Referer header with the Collaborator payload and send the request.
Step 6: Poll for interactions
Go back to the Burp Collaborator client window that you opened earlier.
By default, the Collaborator client polls for interactions every 60 seconds, so you may see some interactions listed already. If not, click Poll now.
The window will show attempted interactions with any Collaborator payloads that it provided. In this case, you should see both HTTP and DNS interactions, proving that you successfully induced the application to send a request for your Collaborator subdomain.
You can click each interaction to view more details about it.
Congratulations, you now know how to:
- Access the Burp Collaborator client
- Use it to generate a proof of concept for asynchronous vulnerabilities, in this case, blind SSRF
This is just an initial proof of concept. To learn how you can exploit this kind of behavior in the wild, check out the Web Security Academy, in particular:
In this tutorial, we manually tested a single input using Burp Repeater. In practice, you may want to test multiple inputs at once using the Collaborator Everywhere extension. When enabled, this automatically injects a number of Collaborator payloads into any requests that pass through Burp Proxy or are sent by Burp's tools.
Collaborator Everywhere injects a different payload into each input, enabling you to easily identify which one caused the interaction with the Collaborator server. You can see this behavior by studying the modified requests in the Logger tab:
After you have identified a vulnerable input location, you can then test it in more detail using Repeater.
Was this article helpful?
An error occurred, please try again.