Testing Asynchronous Vulnerabilities Using the Burp Collaborator Client
In this tutorial, you will learn how to use the Burp Collaborator client to test if you can trick a target site into sending out-of-band asynchronous 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 allows you to take advantage of this during manual testing by providing you with “Collaborator payloads”. These are simply the names of one or more Collaborator server subdomains, for example:
You can try to inject these subdomain names into the application and then query the Collaborator server for attempts to interact with them.
Step 1: Access the lab
Open Burp’s browser and use it to navigate to the following URL:
Click on Access the lab and log in to your PortSwigger account if prompted.
Step 2: Identify a suitable input to test
You must first identify an input used by the application to generate a secondary asynchronous request. For the purposes of this tutorial, let’s assume you already know that this workbench fetches the URL specified in the
Referer header when you load one of its product pages.
Visit a product page and submit the result
GET /product?productId=X ask Burp Repeater.
Step 3: Open the Burp Collaborator client
To open a new Burp Collaborator client window, from the burp menu, select Burp Collaborating Client.
Step 4: Get Payload URL
In the collaborator client window, click Copy to clipboard.
This provides a Collaborator payload and copies it to your clipboard.
You must keep the Burp Collaborator client window open when using a given payload. Each Collaborator client window can only query interactions with the payloads 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 submit the request.
Step 6: Probe interactions
Return to the Burp Collaborator client window you opened earlier.
By default, the Collaborator client polls for interactions every 60 seconds, so you may see some interactions already listed. If not, click Survey now.
The window will show attempts to interact with all provided Collaborator payloads. In this case, you should see HTTP and DNS interactions, proving that you were successful in getting the app to send a request for your Collaborator subdomain.
You can click on 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
And then ?
This is just a first proof of concept. To learn how you can exploit this kind of behavior in the wild, check out the Web Security Academy, including:
In this tutorial, we manually tested a single input using Burp Repeater. In practice, you might want to test multiple entries at once using the Collaborator Everywhere extension. When enabled, this automatically injects a number of Collaborator payloads into all requests that pass through Burp Proxy or are sent by Burp’s tools.
Collaborator Everywhere injects a different payload into each input, allowing you to easily identify which one caused the interaction with the Collaborator server. You can see this behavior by looking at the modified queries in the Recorder tongue:
After identifying a vulnerable input location, you can further test it using Repeater.