Mitigating OWASP API Security Risk: Server-Side Request Forgery (SSRF) using F5 BIG-IP

Introduction

As the world becomes increasingly interconnected, APIs (Application Programming Interfaces) have become a vital part of modern software development. They allow different systems to communicate and share data seamlessly. However, with the rise in API usage comes an increased risk of security vulnerabilities. One of the most dangerous vulnerabilities on this list is Server-Side Request Forgery (SSRF).

SSRF is a complex but serious vulnerability that can be exploited by attackers to gain access to internal systems, bypass security measures, and even leak sensitive data. Despite its potential impact, SSRF is often overlooked, making it a significant threat for organizations and developers. In this article, we’ll explore what SSRF is, how it works, its real-world consequences, and how to mitigate the risk in your API infrastructure.

 

What is SSRF?

Server-Side Request Forgery (SSRF) occurs when an attacker tricks a vulnerable web application into sending requests to unintended locations. Typically, this happens when an application allows users to provide a URL that the server will use to fetch data from a different endpoint. If the application doesn’t properly validate or restrict where these requests can go, an attacker can manipulate the URL to target internal resources, such as private APIs, databases, or even metadata services in cloud environments.

Example:

Imagine a weather API that allows users to input a city name, and the server fetches the weather data from an external service using the specified URL. If the application doesn’t restrict where the server can send requests, an attacker might input a URL that points to an internal resource, like a database or admin interface, rather than a legitimate external API.

 

• A user requests data from https://demoapp.com/weather?city=London.
• An attacker could manipulate the input to http://localhost:8080/admin or http://169.254.169.254/latest/meta-data/ (a common URL for accessing metadata in cloud environments like AWS).
• The server, instead of fetching weather data, now makes a request to a sensitive internal resource, potentially exposing critical data or enabling further attacks.

 

Attack Demonstration:

For this demonstration, we will see how we can exploit the SSRF vulnerability in ‘CRAPI’ application. This application is added as a pool member to BIG-IP and can be accessed via a virtual server. For more information, refer to how to add pool member .

In the ‘Contact Mechanic’ option of the CRAPI application, If a user submits a request to contact the mechanic, in the request payload if we take a close look, internally, the application is making one more  API call to ‘x.x.x.x/workshop/api/mechanic/receive_report’ to fetch the report from the mechanic. i.e. the application is executing the receive report URL.

 

Attackers can exploit this vulnerability by replacing the URL in the payload with any malicious URL or URLS like ‘http://localhost:8080’, ‘http://localhost:8888’ or any other ports to find out the open ports in the application.

Let us try to replace URL with ‘http://localhost:8080’ and see what happens

From the response, it is evident that port 8080 is open and a tomcat web application is running on it. Attackers can perform attacks like Buffer overflow, Traffic Flooding, etc.. to bring down the application running on that port.

Mitigation using BIG-IP Advanced WAF:

 

Login to BIG-IP console, Navigate to Security > Application Security > Security Policies > and create an application policy with below configurations.

Policy Template: API Protection

Enforcement mode: Blocking

Signature Staging: Enabled

Policy Building Learning Mode: Automatic

Virtual Sever:  < Virtual server on which juice shop application is accessible>

Other configs are set to default values

Note: Staging is enabled by default while creating the application security policy and the default staging period is 7 days. It can be tuned according to the customer requirement. For more information related to staging, refer to Attack Signatures & Staging.

As per your application, get the open API specification file from developer or repo. In the BIG-IP console, upload the respective Open API Specification file by clicking the upload file button.  

Here is the reference configuration screenshot that I have configured for the /contact_mechanic endpoint. Under the schema section, I have explicitly specified the IP/domain the URL should begin with

Now let’s re-initiate the request and observe what happens in response.

The request got blocked since the URL in our request payload is not matching with the URL pattern specified in the Open API spec (Swagger) file.

Advanced WAF events also prove that request got blocked successfully since “JSON data does not comply with JSON schema”

Conclusion:

SSRF is a dangerous vulnerability that can have far reaching impacts on an application’s security, allowing attackers to access internal systems or exfiltrate sensitive data. This article covers the basics of SSRF attack along with attack demonstration and how this attack can be effectively mitigated using F5 Advanced WAF.

For further information, please refer to:

Mitigating OWASP API Security Risk : SSRF Using F5 Distributed Cloud

Server Side Request Forgery ( SSRF ) - OWASP