Exploiting SSRF in FilePond’s API with the ?fetch= Call: A Penetration Tester’s Guide

Note: All screenshots included in this article have been intentionally blurred to protect the confidentiality and security of the company involved. My goal is to share knowledge and insights into identifying and mitigating security vulnerabilities without exposing sensitive information.

Introduction to FilePond and SSRF

FilePond is widely used for handling file uploads in web applications due to its simplicity and flexibility. It allows various server configurations, including processing, reverting, loading, restoring, fetching, and patching files. Among these functionalities, the fetch operation is particularly interesting from a security standpoint because it can be use to retrieve files from URLs provided by the user.

SSRF vulnerabilities occur when an attacker can control the URL to which the server makes a request. In the context of FilePond, if an attacker can manipulate the ?fetch= call to point to an internal resource, they can potentially access or interact with files that the web server can reach, but which are not accessible directly from the outside.

Identifying the Vulnerability

I encountered a file upload feature on a web page and recognized it was using FilePond for file handling. Intrigued by its implementation, I inspected the source tab through Firefox’s Developer Tools. This investigation revealed the path to the FilePond API, indicating that the server was configured to use FilePond’s default server settings.

Curious about the FilePond’s functionality, I went over the official FilePond documentation. To my surprise, I discovered the availability of fetch call designed to retrieve files from specified URLs by passing a parameter through the ?fetch=<url> query string. I knew the potential for exploitation so I decided to test the endpoint for SSRF.

Example Server Configuration:

FilePond.setOptions({
    server: './',
});

This configuration assumes all API methods, including fetch, are available on the same base URL as the current page.

Exploitation Method

To exploit the SSRF vulnerability with the ?fetch= parameter:

1. Investigation: Check the path to the FilePond server processes and if the fetch request is available.
2. Payload Crafting: Craft a URL pointing to an internal service/sensitive external service that the server can access. This URL will be used as the fetch parameter.
3. Execution: Insert the crafted URL as the fetch parameter in a request to the FilePond server. For example, if you’re targeting an internal metadata service that is only accessible within the target environment, your request might look like this:
   https://example.com/filepond?fetch=http://internal-service/metadata
4. Observation and Analysis: Monitor the response from the server and any side effects that occur. If the server attempts to connect to the specified URL without proper validation, it indicates an SSRF vulnerability.

I went ahead and tested if I could read /etc/passwd and it worked:

Mitigation Strategies

To protect against SSRF attacks via the ?fetch= call in FilePond, consider implementing the following security measures:

• Whitelist Allowable URLs: Only permit URLs from a predefined list of safe domains to be fetched.
• Disable Unnecessary Functionality: If the fetch functionality is not needed, disable it entirely.
• Input Validation and Sanitization: Implement strict validation on the input URLs to ensure they conform to expected formats and domains.
• Use of SSRF Protection Libraries: Employ libraries or frameworks that offer built-in SSRF protections.

Conclusion

While FilePond offers convenient functionalities for file handling in web applications, it’s important to be aware of potential SSRF vulnerabilities, particularly through its ?fetch= functionality. By understanding how to identify and exploit these vulnerabilities, we can help secure applications against SSRF attacks.