Server-Side Request Forgery: Proactive SSRF Prevention Tactics for Developers

Introduction SSRF:

Server-Side Request Forgery (SSRF) is a type of web application vulnerability that allows an attacker to send crafted requests from a vulnerable server to an arbitrary destination. This can allow the attacker to access sensitive information, such as internal network resources, by making requests on behalf of the vulnerable server. SSRF attacks can also be used to launch further attacks, such as port scanning and denial of service attacks.

What is SSRF?

In a Server-Side Request Forgery (SSRF) attack, an attacker manipulates the functionality of a server to gain access or modify resources. An attacker manipulates a server into accessing resources that it was not intended to access. This is done by altering a URL that the server uses to retrieve data, such as an image or file upload link, and redirecting the server to a malicious URL. When the manipulated request is sent to the server, the server-side code attempts to read data from the altered URL, potentially allowing the attacker to access information that is not intended to be publicly available.

To safeguard against SSRF attacks, it is crucial for developers to implement best practices and security measures in their applications and API endpoints.

Attacks scenarios and preventions:

1. Exploiting Internal Resources (Localhost) via SSRF: Accessing and reading files from the server through the internal network by targeting the administrator panel (/admin), which is only accessible within the internal network, is an example of exploiting internal resources via SSRF.

Example: https://www. example. com/index?ImageUrl=http://127.0.0.1/admin

‍Example of how SSRF vulnerability could be introduced and mitigated in a more complex web application using a PHP framework such as Laravel:

This controller takes a user-supplied $url parameter, reads the contents of the URL using file_get_contents(), and returns it as a download to the user. An attacker could exploit this vulnerability by crafting a URL that points to a file on the server's file system, such as "file:/// etc/passwd", and passing it as a parameter in the request. This would allow the attacker to read sensitive files on the server.

To mitigate this vulnerability, Developers can use Laravel's built-in validation and sanitization functions to ensure that only safe URLs are accepted:

Here we use the validate() method of the Request object to validate that the url parameter is present and is a valid URL. This will prevent an attacker from passing in a malicious file URL.  This will not prevent an attacker from putting in URLs like 127.0.0.1/admin or http://169.254.169.254/latest/meta-data/, to prevent this you could use a whitelist of URLs only to allow specific URLs to be passed to the controller. This will prevent the attacker from passing any malicious URLs.

2. Exploiting Cloud Metadata (AWS): Accessing metadata on Amazon Web Services (AWS), SSRF can be used to obtain sensitive information about the AWS environment, such as the internal IP addresses of the servers, the IAM role associated with the instance, and the metadata of the IAM role. Check out these AWS metadata tests by Akto.

1. sensitive-aws-details-exposed-via-replacing-url-param-with-encoded-url-due-to-ssrf

2. sensitive-aws-details-exposed-due-to-ssrf

3. sensitive-aws-details-exposed-via-replacing-csv-param-due-to-ssrf

4. sensitive-aws-details-exposed-via-replacing-image-param-due-to-ssrf

5. sensitive-aws-details-exposed-via-replacing-file-param-due-to-ssrf

6. sensitive-aws-details-exposed-via-replacing-xml-param-due-to-ssrf

7. sensitive-aws-details-exposed-via-replace-pdf-param-due-to-ssrf

An example of an SSRF vulnerability in the context of AWS metadata access is an API endpoint that allows users to upload images but does not properly validate the file type. An attacker could upload a specially crafted file that includes a request to the AWS metadata endpoint (http://169.254.169.254/latest/meta-data/) as the file content. The server-side script that processes the image upload would then send this request to the AWS metadata endpoint, and the attacker could obtain sensitive information about the environment.

Here is an example of a Python script that demonstrates this vulnerability:

In this example, the attacker creates a file called "ssrf.jpg" with the content "GET http://169.254.169.254/latest/meta-data/" and then uploads this file to the web application using the upload_image() function. The server-side script that processes the image upload would then request the AWS metadata endpoint, and the attacker could obtain sensitive information about the environment.

It's important to note that this is a simplified example, and in real-world scenarios, the validation of the file and the request will be more complex.

Here is a python script that demonstrates how to prevent this type of SSRF vulnerability:

In this example, the upload_image() function has been modified to check the file content against a whitelist of allowed domains before sending the request. The is_valid_url() function is used to parse the URL and check the domain against the whitelist. If the domain is not in the whitelist, the function returns False, and the upload is rejected. This prevents an attacker from uploading a file containing a request to an unauthorized domain, such as the AWS metadata endpoint.

It's important to note that this is a simplified example, and in real-world scenarios, the validation of the file and the request will be more complex.

It's also important to mention that AWS has mitigated this issue by blocking requests from external IP addresses to the metadata service on IP 169.254.169.254. So, even if an attacker managed to exploit an SSRF vulnerability, the response would be a 403 error. It is important to have security best practices and security controls in place to prevent this kind of attack.