OWASP Top 10 :Understanding Server-Side Request Forgery (SSRF)

  What is Server-Side Request Forgery (SSRF)?

Server-Side Request Forgery (SSRF) is a type of security vulnerability where an attacker can abuse functionality on a server to make HTTP requests to arbitrary destinations. This vulnerability occurs when a web application accepts a URL or some kind of remote resource input and fetches the resource without proper validation or sanitization.

How SSRF Works:

1. Initial Request: The attacker finds an input in the application that takes a URL or an address (e.g., an image URL for uploading, a webhook URL, etc.).

2. Malicious Input: The attacker inputs a malicious URL pointing to an internal system or another target.

3. Server Request: The server processes the input and makes a request to the supplied URL.

4. Response Handling: The server processes the response, which can lead to information leakage or further exploitation.

Impacts:

1. Internal Network Scanning: The attacker can scan and map the internal network, discovering services that are not exposed to the external internet.

Example: An attacker discovers a vulnerable URL parameter in a web application that allows them to make requests to internal resources. By sending requests to various internal IP addresses, the attacker maps out the internal network and identifies services that are not exposed to the internet.

2. Sensitive Information Access: Access to internal resources (e.g., metadata services in cloud environments like AWS, and GCP).

Example: An attacker exploits an SSRF vulnerability to access the metadata service of a cloud provider like AWS. This allows them to retrieve sensitive information such as access keys or instance details that can be used for further exploitation.

3. Port Scanning: Identifying open ports on internal servers.

Example: Using SSRF, an attacker targets an internal server to check which ports are open. By sending requests to different ports on internal IP addresses, they can determine which ports are open and potentially vulnerable.

4. Bypassing Firewalls: Accessing internal services that are otherwise protected by network firewalls.

Example: An attacker uses SSRF to access an internal service that is protected by a firewall. Since the request is made from the server side, the firewall rules that block external traffic do not apply, allowing the attacker to interact with the internal service.

5. Remote Code Execution: Exploiting other vulnerabilities in internal services.

Example: An attacker sends a request to an internal service with a payload that exploits a vulnerability in that service. If the internal service is vulnerable, the attacker may achieve remote code execution or further compromise the system.

Types of SSRF:

1. Basic SSRF: The server fetches a URL specified by the attacker.

Example:http://example.com/fetch?url=http://attacker.com

2. Blind SSRF: The attacker cannot see the response but can infer actions based on timing or side effects.

Example: http://example.com/fetch?url=http://internal-system/resource

3. Subdomain Takeover SSRF: The attacker uses DNS rebinding or subdomain takeover techniques.

Example: http://example.com/fetch?url=http://subdomain.attacker.com

4. URL Redirection SSRF: Exploiting open redirections in the application.

Example: http://example.com/redirect?url=http://attacker.com

5. Out-of-Band (OOB) SSRF: Using an out-of-band channel to get the response (e.g., via DNS).

Example: http://example.com/fetch?url=http://attacker.com/resource

6. Parameter-based SSRF: Manipulating URL parameters to access internal resources.

Example: http://example.com/fetch?file=../../../../etc/passwd

7. Second-Order SSRF: When the initial request does not cause the SSRF but triggers another server action that does.

Example: http://example.com/upload?file=http://attacker.com/resource

Prevention:

1. Input Validation: Strictly validate and sanitize user inputs.

Example: A web application that allows users to input URLs for fetching data implements strict validation. The validation checks if the URL belongs to a trusted domain or if it conforms to a specific format before making the request. For example, the application only allows URLs that match a predefined pattern and rejects any input that includes internal IP addresses or localhost.

2. Allow listing: Only allow requests to predefined, trusted URLs or domains.

Example: An application is configured to only allow requests to a list of predefined, trusted domains. For instance, the application’s URL fetching functionality is restricted to access only known API endpoints or services that are essential for its operation, such as https://api.example.com.

3. Network Segmentation: Separate critical internal services from the public-facing ones.

Example: A company segments its network by placing internal services in a separate, isolated network segment that is not directly accessible from the public internet. This means that even if an SSRF vulnerability is exploited, the attacker cannot directly reach sensitive internal services.

4. Use DNS Resolution: Resolve hostnames to IP addresses before making requests to ensure they are not internal addresses.

Example: Before making a request to a URL provided by the user, the application resolves the hostname to an IP address and checks if it falls within a range of trusted IP addresses. If the resolved IP address is internal or belongs to a non-trusted network, the request is blocked.

5. Limit Response Data: Limit the amount of information returned from the server's response to reduce leakage.

Example: An application that processes requests from external sources limits the amount of data it returns. For instance, it truncates the response to a maximum length or excludes sensitive information from being included in the response. This reduces the risk of exposing internal details or sensitive data through SSRF vulnerabilities.

Conclusion: Server-side Request Forgery (SSRF) is a critical security vulnerability that allows attackers to manipulate server-side requests to access or interact with internal systems. This can lead to a wide range of malicious activities, including unauthorized data access, internal network scanning, and even remote code execution.