Mitigation of OWASP API Security Risk: SSRF using F5 Distributed Cloud Platform

Overview:

In OWASP API Security 2023 report, Server-Side Request Forgery (SSRF) is newly added as one of the top 10 vulnerabilities. This article is a continuation of the series of articles on OWASP API Security vulnerabilities and demonstrates a scenario for mitigating SSRF API Vulnerability using F5 Distributed (XC) Cloud Platform.

Introduction to SSRF API Vulnerability:  

In a typical SSRF attack, an intruder identifies a vulnerable API endpoint within the application and sends an unauthorized request allowing it to access internal resources, fetch sensitive data or to connect the external systems. One of the common reasons for this is limited or lack of user input data validation.  

To overcome this vulnerability, proper Input validations should be performed on user-provided input data to ensure only legitimate requests are allowed. Mainly data fields which accept URLs as input should be thoroughly validated. Allow lists should be maintained so that only trusted requests/calls are processed. 

Demonstration: 

For demonstration purpose, let us solve a SSRF challenge in crAPI(completely ridiculous API) application and mitigate it using F5 XC API protection feature.  

Note: crAPI is a vulnerable application designed for training purposes and can be a helpful tool to understand the OWASP top 10 most critical API security risks. For more details, you can refer to OWASP crAPI repository.

Challenge: Make crAPI application send an HTTP call to "www.google.com" and return the HTTP response. 

Prerequisites:

1. Deploy crAPI application by following the steps provided in quickstart guide.
2. Add an origin pool with deployed crAPI application server details.
3. Create an HTTP load balancer in XC console with origin pool attached to it. For detailed steps, please refer to HTTP Load Balancer document.

Now that we have all the prerequisites ready, let us identify vulnerable endpoint within the application and make a HTTP call to www.google.com

Steps to generate attack:

1. Access the application using Load Balancer domain name. Create an account and login to the application using the created credentials.
2. Navigate to Dashboard section and observe the vehicle details page.
3. Click on ‘Contact Mechanic’ and provide required details like Mechanic name, Problem Description and send Service Request.
   
   
4. Observe Endpoint and payload details while making the service request. Below image shows that ‘contact_mechanic’ endpoint is internally making a call to ‘mechanic_api’ URL. Since ‘mechanic_api’ parameter accepts URL as data, this can be vulnerable to SSRF attacks.  
   
   

    

   

    

5. As shown in the image below, using the postman tool, we can exploit the vulnerable endpoint by modifying the URL call to www.google.com in POST data and observe the response shows 200 status code. Attackers can take advantage of such endpoints and gain access to internal resources which are forbidden to access externally. 
   
   

Mitigation using F5 XC API Protection:

To mitigate this, let us now configure XC to validate all the API endpoints according to the provided swagger file and block the requests which have any suspicious/unexpected content. 

1. Download crAPI’s swagger file from repo. Make changes in ‘contact_mechanic’ API section of swagger file to validate and allow only valid/allowed URL for ‘mechanic_api’ parameter then save it.
   

    

2. Login to F5 XC console and Edit the Load Balancer associated with crAPI application.
3. Navigate to API Protection section and select “Enable” in API Definition field.
4. Click “Add Item”, Enter a name.
5. Click “Upload Swagger file”, Enter a name and upload the swagger file, which is updated in step 1, Apply changes.
6. Now from your LB main config page, select “All Endpoints” for “Validation” field and click “View Configuration”.
7. Select “Validate” for “OpenAPI Validation Request Processing Mode” field, select “Block” for field “Request Validation Enforcement Type” and select all available properties in “Request Validation Properties” field.
8. Click “Show Advanced Fields” toggle button, choose “Custom” under “Property Validation Settings”, select “Disallow” under “Allow/Disallow additional query parameters in Request” and apply the changes.
   Note:  Above configurations will allow XC to validate all the Requests to API endpoints and enforce block mode if the request parameters do not meet the requirements mentioned in the uploaded swagger file. "Allow/Disallow additional query parameters in Request" option in Advanced section helps XC to validate and block any additional query parameters that are being sent in request. 
   
   

    

9. Try to repeat the above attack scenario by providing www.google.com in the “mechanic_api” parameter and validate that the request is blocked.
   

    

10. With API protection, LB allows requests which have only a valid URL endpoint.
    

     

11. Monitor the “Security Analytics” logs from F5 XC console and observe security events triggered for blocked requests.
    

     

    

     

Conclusion:

F5 XC API protection solution is very effective in mitigating many API security risks. As shown in the above demonstration, F5 XC supported Open API Validation feature helps to prevent SSRF security attacks. 

Reference Links: 

1. OWASP API Security Project 
2. F5 Distributed Cloud Services 
3. F5 Distributed Cloud WAAP 
4. Introduction to OWASP API Security Top 10 2023