Attacking APIs with SSRF and how to prevent it

Based on the 2023 OWASP API Security Top 10 this is one of the common attack types. The exploitability and detectability are easy making it quite dangerous.

Server-Side Request Forgery (SSRF) flaws occur when an API is fetching a remote resource without validating the user-supplied URL. It enables an attacker to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall or a VPN.

This essentially tricks the server into acting as a proxy, allowing the attacker to interact with and send requests to external systems from the server, bypassing firewalls and accessing restricted areas.

In a typical SSRF scenario, the attacker might find a vulnerability within an application that makes a request to a URL specified by user input. By providing a malicious URL, they can manipulate the server to make requests to internal resources, for instance to cloud service metadata APIs, internal networks, or other services which are only accessible from the server’s perspective.

Example Attack Scenario

A social network allows users to upload profile pictures. The user can choose either to upload the image file from their machine, or provide the URL of the image. Choosing the second, will trigger the following API call:

POST /api/profile/upload_picture

{
  "picture_url": "http://example.com/profile_pic.jpg"
}

An attacker can send a malicious URL and initiate port scanning within the internal network using the API Endpoint.

{
  "picture_url": "localhost:8080"
}

Based on the response time, the attacker can figure out whether the port is open or not.

Mitigation strategies

1. Allowlisting URLs: Rather than allowing any URL, only allow URLs from a known, safe list (if it’s possible).
2. Isolate the resource fetching mechanism in your network: usually these features are aimed to retrieve remote resources and not internal ones.
3. Block private IP address ranges: This would stop attackers from accessing services running on localhost or on internal networks.
4. Rate limiting: Limit the number of requests per user to prevent DoS attacks.
5. Disable HTTP redirections.
6. Validate and sanitize all client-supplied input data.
7. Do not send raw responses to clients.

Knowing how the attack works will help you to implement applicable prevention mechanisms.

Hope this helpful.