**Note: The content in this article is only for educational purposes and understanding of cybersecurity concepts. It should enable people and organizations to have a better grip on threats and know how to protect themselves against them. Please use this information responsibly.**
Server-side request forgery, where an attacker tricks the server-side application into making requests to unintended destinations. In this kind of attack, the attackers can make the server connect to internal services. These services are off-limits within a company’s network. Alternatively, the attacker might force the server to connect to external systems, potentially exposing sensitive data such as authorization credentials.
Reasons for SSRF Vulnerabilities
Applications often exhibit SSRF vulnerabilities due to several reasons, particularly related to how they handle requests from the local machine:
- Implicit Trust in Local Requests: Many applications trust requests made from the local machine, assuming that any request originating from the server is legitimate. This is often a result of misconfigured access controls or overly permissive settings.
- Access Control Bypass: Access control checks may occur in a separate component or before the application server. When the server itself initiates a connection, it may bypass these checks, allowing unauthorized access.
- Disaster Recovery Features: Some applications implement features that allow administrative access without authentication for users connecting from the local machine. This assumption relies on the belief that only trusted users will make requests from the server.
Walkthrough: Basic SSRF against the local server
In this demo application at this link: Lab: Basic SSRF against the local server | Web Security Academy (portswigger.net), there’s a stock check feature that retrieves data from an internal system. To successfully complete the lab, modify the stock check URL to access the admin interface located at http://localhost/admin. Once there, proceed to delete the user named Carlos.
- Keep in mind that you can’t get to the /admin page.
- Follow these steps:
a. Initiate the Stock Check Request:
Navigate to any product page in the application.
Locate and click the “Check Stock” button. This action sends a request to the server to verify stock availability.
b. Intercept the Request:
Use a web proxy tool, such as Burp Suite, to intercept the application’s request.
Right-click on the request and click on Send to Repeater.
c. This request shows up in the repeater. This will allow us to modify and resend the request.
- Modify the Request:
In the repeater tool, find the parameter that specifies the stock API endpoint (usually labeled as stockApi).
Change the stockApi value from the original endpoint to http://localhost/admin. This manipulation directs the request to the admin interface instead of the intended stock check service.
Once you’ve made the change, send the modified request to the server. The server will process this request as if it originated from a legitimate source.
- Identify the Delete User Endpoint:
Review the response received in the repeater. Look for any indication or link that directs to the admin interface’s user management features.
Specifically, search for the user deletion path for Carlos. This path will typically be formatted as: http://localhost/admin/delete?username=carlos.
- Replace the Path in the Stock API:
Now, return to the original request and replace the modified stockApi value with the deletion path you found. The new value should look like this: http://localhost/admin/delete?username=carlos
User Carlos account will be deleted at this step.
Summary Points of SSRF Walkthrough
- Objective: Exploit an SSRF vulnerability to access the admin interface of an application and delete a user named Carlos.
- Initiated Stock Check: Clicked the “Check Stock” button on a product page to generate the initial request.
- Intercepted Request: Used a web proxy tool to capture the stock check request and sent it to the repeater for modification.
- Modified API Endpoint: Changed the stockApi parameter to point to http://localhost/admin, redirecting the request to the admin interface.
- Identified Deletion Path: Examined the response to find the user deletion endpoint for Carlos, formatted as http://localhost/admin/delete?username=carlos.
- Replaced Path in Request: Updated the stockApi parameter in the original request with the deletion path.
- Executed Deletion: Sent the modified request, which instructed the server to delete Carlos’s user account.
- Mitigation Strategies: Emphasized the need for input validation, restricting outbound requests, and network segmentation to prevent SSRF vulnerabilities in applications.
