# 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.

3. 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.

4. 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.

5. 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.

6. 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](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Server%20Side%20Request%20Forgery).

7. 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! --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://davidjosearaujo.gitbook.io/online-courses/api-penetration-testing-course/exploiting-server-side-request-forgery/testing-for-ssrf.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.