PROFESSIONAL

Testing for asynchronous vulnerabilities using the Burp Collaborator client

• Last updated: May 17, 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:

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.

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.

Summary

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

What next?

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:

• Blind SSRF
• Blind SQL injection

Collaborator Everywhere

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.