Web Fundamentals | SSRF
Hi there, I’m glad to see you here. In this article, we’ll examine together the “SSRF” room in PortSwigger. In some sections, I’ll share brief about the subject. Don’t forget! You must always research to learn more. I hope it will be helpful for you. Let’s start!
Contents:
- What is an SSRF?
- Basic SSRF against the local server
- Basic SSRF against another back-end system
- SSRF with blacklist-based input filters
- SSRF with whitelist-based input filters
- SSRF with filter bypass via open redirection vulnerability
What is an SSRF?
Server-Side Request Forgery (also known as SSRF) is a web security vulnerability that allows an attacker to induce the server-side application to make requests to an unintended location.
A successful SSRF attack can often result in unauthorized actions or access to data within the organization, either in the vulnerable application itself or on other back-end systems that the application can communicate with.
Basic SSRF against the local server
❗️In an SSRF attack against the server itself, the attacker induces the application to make an HTTP request back to the server that is hosting the application, via its loopback network interface. This will typically involve supplying a URL with a hostname like 127.0.0.1 or localhost.
👉🏼When we access the lab environment, we’re greeted by a shopping site. We can view any product by clicking the “View details” button.
👉🏼And then we can click the “Check stock” button to see how much the product is available in which city.
👉🏼When we intercept the request, we can see that the stock information of a product is received via API.
👉🏼Let’s change the URL in the “stockApi” parameter to “http://localhost”.
👉🏼When we look at the “Response” section, we can see that the request received an “HTTP 200 (OK)” response because there is no protection.
👉🏼Let’s change the URL in the “stockApi” parameter to “http://localhost/admin”. This should show us the admin interface.
👉🏼We can change the URL in the “stockApi” parameter to “http://localhost/admin/delete?username=carlos” to delete the “Carlos” user.
👉🏼And when we return to the admin panel, we can see that the user has been deleted successfully.
Congratulations, you solved the lab! 👊🏼
Basic SSRF against another back-end system
❗️Another type of trust relationship that often arises with server-side request forgery is where the application server is able to interact with other back-end systems that are not directly reachable by users. These systems often have non-routable private IP addresses.
👉🏼When we access the lab environment, we’re greeted by a shopping site. We can view any product by clicking the “View details” button.
👉🏼And then we can click the “Check stock” button to see how much the product is available in which city.
👉🏼When we intercept the request, we can see that the stock information of a product is received via API.
👉🏼In order to access to the internal system, we can determine the correct IP address through the “Intruder” by using the range and port information provided to us.
Payload type : Numbers
From : 1
To : 255
Step : 1👉🏼We must click on “Start attack” to start the process.
👉🏼When we examine the requests, we can see that the “HTTP 200 (OK)” response is returned for the value “141”.
👉🏼Let’s change the URL in the “stockApi” parameter to “http://192.168.0.141:8080/admin”. This should show us the admin interface.
👉🏼We can change the URL in the “stockApi” parameter to “http://192.168.0.141:8080/admin/delete?username=carlos” to delete the “Carlos” user.
👉🏼And when we return to the admin panel, we can see that the user has been deleted successfully.
Congratulations, you solved the lab! 👊🏼
SSRF with blacklist-based input filters
❗️Some applications block input containing hostnames like 127.0.0.1 and localhost, or sensitive URLs like /admin. In this situation, you can often circumvent the filter using various techniques:
For more payloads:
https://pravinponnusamy.medium.com/ssrf-payloads-f09b2a86a8b4
👉🏼When we access the lab environment, we’re greeted by a shopping site. We can view any product by clicking the “View details” button.
👉🏼And then we can click the “Check stock” button to see how much the product is available in which city.
👉🏼When we intercept the request, we can see that the stock information of a product is received via API.
👉🏼Let’s change the URL in the “stockApi” parameter to “http://localhost/admin”.
👉🏼When we look at the “Response” section, we can see that the request received an “HTTP 400 (Bad Request)” response because the blacklist method was applied.
👉🏼We can use the value “127.1” instead of “127.0.0.1” in the blacklist and the value equivalent to the word “admin” by using the “Double URL Encoding” method from the “Decoder” tab.
👉🏼This should show us the admin interface.
👉🏼We can change the URL in the “stockApi” parameter as shown in the screenshot below to delete the “Carlos” user.
👉🏼And when we return to the admin panel, we can see that the user has been deleted successfully.
Congratulations, you solved the lab! 👊🏼
SSRF with whitelist-based input filters
❗️Some applications only allow input that matches, begins with, or contains, a whitelist of permitted values. In this situation, you can sometimes circumvent the filter by exploiting inconsistencies in URL parsing.
👉🏼When we access the lab environment, we’re greeted by a shopping site. We can view any product by clicking the “View details” button.
👉🏼And then we can click the “Check stock” button to see how much the product is available in which city.
👉🏼When we intercept the request, we can see that the stock information of a product is received via API.
👉🏼Let’s change the URL in the “stockApi” parameter to “http://localhost/admin”.
👉🏼When we look at the “Response” section, we can see that the request received an “HTTP 400 (Bad Request)” response and we can understand that the whitelist method was applied in this section because the host is specified as “stock.weliketoshop.net”.
👉🏼Some URL parsers allow credentials to be entered before the domain name. We can take advantage of this feature to search for and exploit an SSRF vulnerability. Let’s try to enter “localhost” as the username for this.
👉🏼However, we received the error message “Could not connect to external stock check service”.
👉🏼So to bypass this, we need to add a “#” character after the username because the “#” character is used to indicate a URL fragment, which is yet another a URL parser property.
👉🏼Let’s find the value equivalent to the “#” character by using the “Double URL Encoding” method from the “Decoder” tab.
👉🏼When we look at the “Response” section, we can see that the request received an “HTTP 200 (OK)”.
👉🏼Let’s add the “/admin” directory to the end of the URL to access the admin interface.
👉🏼We can change the URL in the “stockApi” parameter as shown in the screenshot below to delete the “Carlos” user.
👉🏼And when we return to the admin panel, we can see that the user has been deleted successfully.
Congratulations, you solved the lab! 👊🏼
SSRF with filter bypass via open redirection vulnerability
❗️It is sometimes possible to circumvent any kind of filter-based defenses by exploiting an open redirection vulnerability.
👉🏼When we access the lab environment, we’re greeted by a shopping site. We can view any product by clicking the “View details” button.
👉🏼And then we can click the “Check stock” button to see how much the product is available in which city.
👉🏼When we intercept the request, we can see that the stock information of a product is received via API.
❗️When we change the URL in the “stockApi” parameter to “http://192.168.0.12:8080/admin” provided to us, we can see that the request received the error message Invalid external stock check url ‘Invalid URL’ as well as the “HTTP 400 (Bad Request)” response. That’s why we need to try something different.
👉🏼Let’s return to the product page and click the “Next product” button.
👉🏼There is a “path” parameter in the request and this could potentially be vulnerable to “Open Redirection”.
👉🏼We can run a test to check if we can redirect to any website.
👉🏼When we look at the “Response” section, we can notice that there is an “Open Redirection” vulnerability here.
👉🏼The next step is to change the “stockApi” value with the vulnerable “nextProduct” endpoint to access the admin interface.
/product/nextProduct?currentProductId=3&path=http://192.168.0.12:8080/admin❗️CTRL + U : URL-encode key characters
👉🏼We can change the URL in the “stockApi” parameter as shown in the screenshot below to delete the “Carlos” user.
/product/nextProduct?currentProductId=3&path=http://192.168.0.12:8080/admin/delete?username=carlos❗️CTRL + U : URL-encode key characters
👉🏼And when we return to the admin panel, we can see that the user has been deleted successfully.
Congratulations, you solved the lab! 👊🏼
And once again, congratulations! We basically learned together how to exploit the “SSRF” vulnerability, which is one of the web application vulnerabilities. 👊🏻
Thank you for your time. See you soon! Until that time.. Happy Hacking ❤
Resource:
