Testing for SSRF

1. Either using Postman or the web browser, proxy the requests that you are targeting to Burp Suite.

2. Next, send the request over to Repeater to get an idea of a typical response.

1. In the case of the return_order request, we are able to return an item once. If we attempt to return the item twice then we will receive a response that the item has already been returned.

1. In order to successfully test this request we will need a valid order_id. So, we will need to purchase several items in order to be able to make several requests to return an item. Use the POST /workshop/api/shop/orders request to purchase several items. If you need to increase your account balance, return to the Mass Assignment exploit. Purchase enough items, so that you can attempt several attacks.

1. To test this successfully we will need to change the attack type to Pitchfork. Note that Pitchfork allows us to pair separate payloads together. In the case of this request, we will want to pair a valid order_id with an SSRF payload. This will allow us to increase the item_id while simultaneously sending over various attack attempts.

1. Set the first payload to valid order_id numbers.

Set the second payload to potentially interesting URLs including your webhook.site URL. For additional SSRF payload ideas check out PayloadAllTheThings SSRF List.

1. Review the results. Look for anomalies and any indication within the response that indicate that we were able to control the remote resources processed by the server. In this case, there is no indication in the response.

Next, make sure to check the webhook.site and see if a blind SSRF attack was successful. Again, the URL was not requested and this request does not appear to be vulnerable. Notice the requests shows 0/500 and the message "Waiting for first request...".

Let's try this out on the contact_mechanic request. Set the attack position, copy and paste the payloads you previously used for URLs, and send the attack. Review the results and see if there is anything interesting.

Sure enough, the localhost requests fail, but the other URLs provided are successful. As far as reviewing for anomalies, we can see that there are a variety of status codes and response lengths. Upon reviewing the responses from the successful requests, we can see that the remote resources we requested were sent back over the API request.

We can also verify that a request was made from the server by visiting our webhook.site page.

Congratulations, you have successfully exploited an SSRF vulnerability! If we return back to the Facebook SSRF bounty guideline, this would be an instance where the SSRF is in production, the response is sent back to us, and we have evidence of the request being made to the web server. In other words, maximum rewards!