Server-side request forgery

This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Server-side request forgery" – news · newspapers · books · scholar · JSTOR (October 2022) (Learn how and when to remove this template message)

Server-side request forgery (SSRF) is a type of computer security exploit where an attacker abuses the functionality of a server causing it to access or manipulate information in the realm of that server that would otherwise not be directly accessible to the attacker.^[1][2]

Similar to cross-site request forgery which utilizes a web client, for example, a web browser, within the domain as a proxy for attacks; an SSRF attack utilizes a vulnerable server within the domain as a proxy.

If a parameter of a URL is vulnerable to this attack, it is possible an attacker can devise ways to interact with the server directly (via localhost) or with the backend servers that are not accessible by the external users. An attacker can practically scan the entire network and retrieve sensitive information.

Types[edit]

Basic[edit]

In this type of attack the response is displayed to the attacker. The server fetches the URL requested by the attacker and sends the response back to the attacker.

Blind[edit]

In this type of attack the response is not sent back to the attacker. Therefore, the attacker has to devise ways to confirm this vulnerability.

Steps[edit]

1. Exploiting Misconfigurations: An attacker identifies a vulnerable endpoint in a web application. This could be, for example, an endpoint that fetches external resources like images or web pages.
2. Crafting the Payload: The attacker crafts a malicious URL targeting internal resources. This could target localhost (127.0.0.1), or other IPs indicative of internal resources, like 10.*.*.* or 192.168.*.*.
3. Bypassing Filters: If there are any filters in place, the attacker might try various techniques to bypass them. For instance, by using an IP address instead of "localhost", or by employing different URL schemes and encodings.
4. Fetching Internal Resources: The vulnerable server processes the malicious URL and makes a request to the targeted internal resource. This could expose internal services, databases, or even cloud-specific metadata, as in the case of the IMDS vulnerability on cloud platforms for example.
5. Exfiltrating Data: Depending on the nature of the SSRF and the responses, the attacker might be able to capture or infer data about the internal network or services.

Examples[edit]

Imagine you have a web application that fetches images from URLs and displays them. A user can enter a URL, and the server will download and display the image.

Expected Use:

User inputs: http://somesite.com/image.jpg Server fetches and displays: image.jpg

SSRF Attack:

Attacker inputs: http://localhost/admin If not protected correctly, the server might try to fetch content from its own local admin panel, thus revealing potentially sensitive data.

Mitigations[edit]

• Whitelisting: Only allow URLs/hosts that you know are safe.
• Block Private IPs: Ensure the application logic blocks requests to private IP address spaces.
• Minimal Permissions: Run services with minimal permissions to eliminate the SSRF vulnerability or so that, even if there's an SSRF vulnerability, the damage can be contained.
• Up-to-date Libraries: Ensure all libraries/frameworks are updated regularly. Some older libraries have known SSRF vulnerabilities.
• Timeouts: Implement reasonable timeouts to prevent attackers from access sensitive resources, especially if those sensitive resources are associated with slower response times (e.g. from 1 query on 1 large chunk of sensitive data).

References[edit]

This computer security article is a stub. You can help Wikipedia by expanding it.

• v
• t
• e