OWASP API7:2023 Server Side Request Forgery(SSRF)

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.

SSRF in Modern Application 🚀

Modern concepts in application development make SSRF more common and more dangerous.

More common - the following concepts encourage developers to access an external resource based on user input: Webhooks, file fetching from URLs, custom SSO, and URL previews.

More dangerous - Modern technologies like cloud providers, Kubernetes, and Docker expose management and control channels over HTTP on predictable, well-known paths. Those channels are an easy target for an SSRF attack.

It is also more challenging to limit outbound traffic from your application, because of the connected nature of modern applications.

The SSRF risk can not always be completely eliminated. While choosing a protection mechanism, it is important to consider the business risks and needs.

Example Attack Scenarios 🕵️‍♂️

Server-Side Request Forgery (SSRF) is a security vulnerability that allows an attacker to induce the server to make requests to other services or resources on behalf of the attacker. Here are two example attack scenarios for SSRF:

Scenario 1: Internal Network Reconnaissance 🔍

Attack Details:

1. Identification of SSRF Vulnerability:

   • The attacker identifies a web application that is vulnerable to SSRF. This could be through manual testing, automated scanners, or analyzing the application's behavior.

2. Crafting Malicious Requests:

   • The attacker exploits the SSRF vulnerability by crafting a malicious request that targets internal network resources. They could use the vulnerable web application to make requests to internal services, such as databases, internal APIs, or management interfaces.

3. Accessing Internal Services:

   • The attacker successfully triggers the SSRF vulnerability, causing the server to make requests to internal services. This may involve accessing sensitive information, retrieving data from databases, or interacting with internal APIs.

4. Mapping Internal Network:

   • By manipulating the SSRF requests, the attacker can gradually map the internal network, identifying live hosts, services, and potentially exploiting further vulnerabilities.

5. Pivoting to More Targets:

   • Armed with knowledge about internal network resources, the attacker can pivot to more critical targets, exploiting additional vulnerabilities and escalating their attack.

Mitigation:

• Validate and sanitize user input to prevent SSRF vulnerabilities.
• Implement strict egress filtering to control the destinations that the server can access.
• Use whitelists to restrict the allowed URLs or IP addresses for outgoing requests.

Scenario 2: Cloud Metadata Abuse ⛅

Attack Details:

1. Discovering SSRF in a Cloud Environment:

   • The attacker identifies an SSRF vulnerability in a web application hosted on a cloud server. Cloud metadata URLs (e.g., http://169.254.169.254) are common targets for SSRF in cloud environments.

2. Exploiting Cloud Metadata Service:

   • Leveraging the SSRF vulnerability, the attacker makes requests to the cloud metadata service, which contains sensitive information about the cloud instance, such as access keys, instance metadata, and security group details.

3. Retrieving Sensitive Information:

   • The attacker successfully retrieves sensitive information from the cloud metadata service, gaining access to credentials, and instance details, and potentially compromising the security of the entire cloud environment.

4. Escalating the Attack:

   • Armed with the compromised credentials and knowledge of the cloud infrastructure, the attacker can further escalate the attack by launching additional attacks, provisioning new resources, or modifying existing configurations.

Mitigation:

• Implement proper input validation to prevent SSRF vulnerabilities.
• Use network-level security controls to restrict access to the cloud metadata service.
• Regularly audit and monitor cloud infrastructure for unusual activities and unauthorized access.

How To Prevent Server Side Request Forge ⚙️

1. Isolate the resource fetching mechanism in your network: usually these features are aimed at retrieving remote resources and not internal ones.

2. Whenever possible, use allow lists of:

3. Remote origins users are expected to download resources from (e.g. Google Drive, Gravatar, etc.)

4. URL schemes and ports

5. Accepted media types for a given functionality

6. Disable HTTP redirections.

7. Use a well-tested and maintained URL parser to avoid issues caused by URL parsing inconsistencies.

8. Validate and sanitize all client-supplied input data.

9. Do not send raw responses to clients.

Final Thought 💡

Guard against SSRF by validating user input, implementing allow lists for accepted resources, and isolating resource fetching mechanisms. Stay vigilant, conduct regular security assessments, and prioritize proactive measures to protect sensitive data from unauthorized access.