Here is a quick and easy way to test if an API endpoint is vulnerable to a Server Side Request Forgery (SSRF) attack. To do this, we can use a website called webhook.site to simulate a payload.
What is SSRF?
We want to test for SSRF whenever we come across an API endpoint that fetches content from another URL, which is a pretty common scenario with APIs. In other words, we are looking at an API endpoint that sends a request to another web resource and displays or executes the content it gets back.
Typically, we are looking for an API endpoint that looks like the following:
https://api.website.com/folder/page?url=https://othersite.com/data
If we can modify the API request to include a different URL as the GET parameter, we can potentially link to a malicious web site that we control and retrieve a payload that will execute when the response is rendered.
A great illustration of this is in vAPI, one of my favorite deliberately vulnerable web applications (and if you’re interested, I have a full walkthrough of vAPI right here).
The vAPI task we are interested in is called ServerSurfer. It’s in the Arena folder in the Postman collection that comes with vAPI. Not sure what I’m talking about? Don’t worry about it, it’s not really important for our purpose here.
If you look at the Get Data request (displayed here in Burp Suite), you can see this is a GET request that includes a URL as a GET parameter (https://roottusk.com in the present case).
When we send the request, the JSON response body includes a key called data with a large blob of text as its value. This text ends with == which hints to some base64 encoded content.
If we decode it using CyberChef, we get some html code. This code is actually the landing page of Tushar Kulkarni‘s web site, the author of vAPI (this man is a legend š). So it’s pretty harmless content.
Now let’s see if we can trick the request by including a different URL.
Testing with webhook.site
Let’s first visit the webhook site. Here, we can create a sample text message and a URL that will send back this message when it’s hit.
First click on the New button (top right of the interface). Then type in some text in the Content field and click Create.
Now copy the URL in the field called Your unique URL.
Head back to Burp Suite and paste this URL as the value of the GET parameter in our request.
When we send the request, we can see the content of the data field that comes back in the response body is a much shorter string of text.
Here if we select the string and base64 decode it using the Inspector (on the right), we can see the text we typed as the content sent back by the webhook URL we create early on.
This demonstrates that the API request we are investigating is vulnerable to SSRF, as we are able to change the URL in the GET parameter and fetch proprietary content that is then returned in the response body.
Blind SSRF
Note that what we have above is an example of a regular SSRF, where data is returned back in the response body.
There is another scenario where the query we are are sending (including the modified URL) may trigger some action but there is no data sent back. This is called blind SSRF.
In such a scenario, we need to go back to our browser on the webhook.site page.
On the left column, we can see that a GET request was sent to our web hook URL.
If you look at the details, you will see in the Hosts field the IP from which the request was sent. This will help you confirm the request did indeed come from your system and confirms a successful blind SSRF.
Closing thoughts
The example described here is a pretty simple use case. In a real life scenario, testing for SSRF may not necessarily be so straightforward. But you get the idea.
Happy hunting!
