Server-side request forgery (SSRF) attacks
Lab: Basic SSRF against the local server
This lab has a stock check feature which fetches data from an internal system.
To solve the lab, change the stock check URL to access the admin interface at http://localhost/admin and delete the user carlos.
Solution
First, we will go into View Details
We should see this page.
When we click on check stock, it will return us with the actual amount
If we take a look at the request, it will look something like this
So we can modify the stockApi to this and send using Repeater
After we send the request, we are able to see the admin page
From there we can see that there is link that we can use to delete carlos. We just need to modify stockApi to this:
After sending this request, we will have delete the user carlos.
Lab: Basic SSRF against another back-end system
This lab has a stock check feature which fetches data from an internal system.
To solve the lab, use the stock check functionality to scan the internal 192.168.0.X range for an admin interface on port 8080, then use it to delete the user carlos.
Solution
Same as the previous lab, we will capture the request for stock number using Burp Suite
We will send it to both Repeater and Intruder.
In Intruder, we will modify the request and set the payload position as shown below
Under the payload, we will use a list of number from 1 to 254
After reviewing the result, we can see that .16 returns 200.
Same as the previous lab, we will modify stockApi to this value in Repeater and send the request
It should delete the user carlos.
Lab: SSRF with blacklist-based input filter
This lab has a stock check feature which fetches data from an internal system.
To solve the lab, change the stock check URL to access the admin interface at http://localhost/admin and delete the user carlos.
The developer has deployed two weak anti-SSRF defenses that you will need to bypass.
Solution
Same as before, we will capture the request that will the return the stock number using Burp Suite and send to Repeater
If we modify the stockApi to follow this
It will return us this
We can try to change the stockApi to follow this
It will still returns us the same message, so we will try to bypass potential defence.
We will test is it they blocked the keyword admin
This time they returned a different result.
This means they blocked the word.
So the next thing we can do is to URL encode the word and put into the request
It still return us with the same message.
Maybe we can try to double encode it instead.
Finally we are able to see the admin web page.
So to delete the user, we can just do this:
After sending the request, we should be able to delete the user carlos
Lab: SSRF with filter bypass via open redirection vulnerability
This lab has a stock check feature which fetches data from an internal system.
To solve the lab, change the stock check URL to access the admin interface at http://192.168.0.12:8080/admin and delete the user carlos.
The stock checker has been restricted to only access the local application, so you will need to find an open redirect affecting the application first.
Solution
First, we need to find request that have open redirection.
When we click on Next product, we can see that there is a request which have open redirection
When we inspect the request, we can see that the request is redirecting to /product?productId=2
So the next step is send the request to get the stock number to Repeater and modify StockApi to be like this:
After sending the request, we should be able to see the admin page
The final step is to modify stockApi to delete carlos
After we send the request, we should be able to see that carlos is deleted.
Lab: Blind SSRF with out-of-band detection
This site uses analytics software which fetches the URL specified in the Referer header when a product page is loaded.
To solve the lab, use this functionality to cause an HTTP request to the public Burp Collaborator server.
Solution
Same as the previous lab, we will capture the request when we view the product information.
When we view the request it will look something like this:
Next, we will highlight the value of Referer and click on Insert Collaborator payload.
When we send the request over, we should be able to see it in Collaborator
Last updated