How to use OAST to detect vulnerabilities in an API

Have you ever come across something in an API you think might be vulnerable, but you just aren’t sure? You believe your exploit might trigger it, but you don’t receive a response to confirm it.

Ya, I’ve been there too.

In this article, I want to introduce you to out-of-band application security testing (OAST) and how you can use it to identify more complex vulnerabilities in an API that you can’t traditionally catch with static application security testing (SAST) or even dynamic application security testing (DAST).

Let’s get right to it!

What is OAST?

Out-of-band application security testing (OAST) is a process that can be used to identify and exploit vulnerabilities in web applications and APIs. OAST is typically performed by identifying and exploiting vulnerabilities in the communication channel between the web application and its backend systems.

OAST can be used to identify vulnerabilities that are not detectable using traditional penetration testing techniques. These include things like blind SQL injection (SQLi), blind cross-site scripting (XSS), and blind command injection vulnerabilities.

In essence, OAST works by sending an attack payload that causes the API to interact with an external system we have control over that sits outside the target domain.

And if you have the professional edition of Burp Suite, you have one of the most powerful built-in tools to accomplish this.

It’s called the Burp Collaborator.

What is Burp Collaborator?

The Burp Collaborator is a network service that Burp Suite uses to capture the results of many kinds of vulnerabilities that it can’t capture on its own.

When Burp Collaborator is used, Burp sends payloads to the API being tested 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:

This is done automatically when the Burp Scanner is run. But you can also use it manually with the Burp Collaborator Client. I’ll show you how to do that in a moment… but first, let’s talk about how it works behind the scenes.

How does Burp Collaborator work?

So PortSwigger (the makers of Burp Suite) offers the Burp Collaborator server service as part of your subscription to Burp Suite Pro or Enterprise and exposes an implementation of several network services as collectors:

• It uses its own dedicated domain names, and the server is registered as the authoritative DNS server for these domains. These include *.burpcollaborator.net and *.oastify.com.
• It provides a DNS service that answers any lookup on its registered domains (or subdomains) with its own IP address.
• It provides an HTTP/HTTPS service and uses a valid, CA-signed, wildcard TLS certificate for its domain names.
• It provides an SMTP/SMTPS service.

If you aren’t comfortable sending responses to your attack payloads to servers hosted by PortSwigger, you can host your own private Burp Collaborator server. You can find instructions on deploying your own server here.

Using the Burp Collaborator client

To demonstrate how to use the Burp Collaborator client, let’s walk through one of the blind SSRF labs in Web Security Academy.

Launch Burp and go to the SSRF lab

Open up Burp Suite, and go to the Proxy tab. Under Intercept, click the button to Open Browser. This will launch a Chrome browser already configured to direct all traffic through Burp Suite.

Once the browser opens up, head to https://portswigger.net/web-security/ssrf/blind/lab-out-of-band-detection. Log into the Web Security Academy if you haven’t already.

Now click the green Access the lab button to launch the lab. This opens your own instance of a shopping website that exposes a blind SSRF vulnerability.

Send a request to Burp Repeater

Browse the shopping website by clicking on a few products. Then go back to Burp, go to Proxy > HTTP History, right-click on one of the GET requests to /product?productId=[...], and select Send to Repeater.

Inject a Burp Collaborator payload into the request

Go to the Repeater tab. Highlight the URL in the Referer header, right-click, and select Insert Collaborator payload. This replaces the Referer URL with a URL that points to the Collaborator server.

In this example, it set it to ssoy4fbatuw76vb0fsxthva0brhi58tx.oastify.com:

TIP: Careful on the insert. Make sure you do not highlight the http protocol portion. In the above example, it clobbered over the HTTP protocol handler (http://), and it had to be added back in manually.

Now send the request.

Poll for interactions

Once you have sent a possible request that can trigger an out-of-band action, we want to check it. Click on the Collaborator tab. The Collaborator tab checks every 60 seconds. If you are impatient, you can always click “Poll now.”

Interactions received as a result of your Collaborator payloads are displayed. This confirms that the target site made a request to the arbitrary server. Here is an example from another session:

Notice how the Collaborator client not only shows the activity, it tracks the requests and responses. Be it an HTTP request or DNS query, the entire interaction is recorded for your review… after the fact.

Using OAST for blind SSRF detection in an API

OK, so now that we have a good idea of how to use Burp Collaborator as part of our out-of-band application security testing, let’s try it against our favorite completely ridiculous API, crAPI.

crAPI has a blind server-side request forgery (SSRF) vulnerability in its mechanics API. Let’s step through and demonstrate how to find that.

1. In your Chrome browser currently attached to Burp, go to http://crapi.apisec.ai and login. (Or register first if you haven’t already)
2. Register your vehicle if you haven’t already. If you need your VIN and PIN code, go to http://crapi.apisec.ai:8025 and get the email from MailHog.
3. Click “Contact Mechanic” from your dashboard, and complete the form.
4. Go back to Burp and look in the HTTP History for the POST request /workshop/api/merchant/contact_mechanic. Right-click on it and select Send to Repeater.
5. Go to the Repeater tab, and select the tab to show the body as Pretty.
6. Highlight the URL value in the mechanic_api property, right-click and select Insert Collaborator payload. Make sure it starts with https://.

7. Send the request
8. Go to the Collaborator tab.
9. Click Poll now.
10. You should now see that the contact mechanic API did indeed conduct a blind SSRF request.

Check out my article on taint analysis if you want to know how you could exploit this blind SSRF vuln to get a reverse shell on the identity microservice of the API.

Conclusion

Detecting out-of-band vulnerabilities in an API can be a tricky process, but it’s worth it to ensure the security of the target application programming interfaces you are responsible for testing. Burp Suite’s Collaborator client makes it easy to inject payloads into requests and poll for interactions, making it simple to detect potential vulnerabilities.

In this article, we explored how to use the Collaborator client to find a blind SSRF vulnerability in a shopping website. We then applied the same techniques against a backend API.

You can use your own imagination where to take it from here.

Of course, if you want more insights, check out some other online resources in my free ebook of the Ultimate Guide to API Hacking Resources.