Mitigating OWASP API Security Risk: Security Misconfiguration using F5 XC Platform

Overview

This article is a continuation of the series of articles on OWASP API Security vulnerabilities and demonstrates a scenario for mitigating API Security Misconfiguration using F5 Distributed Cloud(XC) Platform.   

See F5 Distributed Cloud API Security dynamically discover and automatically protect API endpoints.

Introduction to OWASP API Security Misconfiguration

APIs are the backbone of the modern application development model and because of their heavy usage they often become victim of attacks. Sometimes these vulnerabilities arise if security best practices are missed and are not followed properly in application development life cycle. 

Below are a few scenarios which fall under API Security Misconfiguration category: 

• Latest security patches are not applied.
• Unnecessary HTTP verbs are enabled exposing APIs to get accessed by them.
• Improper implementation of CORS policy.
• Missing repeatable security hardening process.
• Exposing detailed stack trace error messages or sensitive information.

Problem Statement

Improperly configured CORS policies can expose web applications to vulnerabilities, allowing malicious actors to perform unauthorized actions or access sensitive data. This poses significant risks to user privacy, application integrity, and organizational security.

In the demonstration below we will cover a scenario where the application is vulnerable to CORS and will see how F5 Distributed Cloud WAAP can help in identifying and mitigating such threats.

What is Cross-Origin Resource Sharing (CORS) ? 

CORS is a security feature implemented by browsers to allow or block web applications from making requests to domains other than their own. This mechanism helps prevent certain types of attacks, by ensuring that only authorized domains can access certain resources. CORS occurs only when the target server(cross-origin) is accessed from other domains and sub-domains. CORS works by specific HTTP/S headers that allow a server to explicitly specify which origins are allowed to access its resources and which methods and headers can be used.

Preflight Request: When making cross-origin requests that are complex (i.e., requests that use non-simple  methods, custom headers, or credentials), the browser sends an OPTIONS request before the actual request which is called the preflight request. The preflight request is used to check if the server will allow the actual request. Specifically, a preflight request occurs when a web page makes a cross-origin HTTP request that does not meet the simple request criteria defined by the CORS specification.

    Consider the scenario below, where authentication request in the origin server is handled by some third-party cross-origin server. If the cross-origin server is not configured to block untrusted origins based on domain, methods and headers, attacker can take advantage of this vulnerability by performing harmful action using methods and headers in requests.

Fig 1 - Misconfigured cross-origin web server allowing all requests

1. Users access the origin web server through web browser and enters the credentials for authentication. Authentication request will be transferred to cross-origin web server for authentication.
2. Authentication request from origin contains non-simple header (X-Custom-Header), as per CORS specification browser sends a Preflight Request to cross-origin, with all the details of actual request.
3. Cross-Origin responds back with Preflight Response where it’s allowing all the requests.
4. Browser checks the preflight response and since all the requests are allowed, actual request containing the payload is sent to the cross-origin.
5. Cross-Origin responds back with the authentication token.

In this scenario, since all the origins, methods and custom headers are allowed by cross-origin, the attacker can craft a malicious request to modify or delete the content in cross-origin server from any origin server.