Mitigating OWASP Web Application Risk: Vulnerable and Outdated Components using F5 BIG-IP
This article provides information on the Struts 2 vulnerability (CVE-2017-5638) , one of the dangers posed by vulnerable and outdated components. It highlights how a single unpatched vulnerability in a widely used framework can lead to catastrophic consequences, including data breaches, server compromise, and damage to an organisation's reputation and how we can protect it using F5 BIG-IP Advanced WAF.Mitigating OWASP 2023 API Security Top 10 Risks Using F5 NGINX App Protect
The OWASP API Security Top 10 highlights the most critical security risks facing APIs, as a global standard for understanding and mitigating vulnerabilities. Based on extensive data analysis and community contributions, the list identifies prevalent vulnerabilities specific to the unique attack surface of APIs. The 2023 edition introduces new vulnerabilities like Unrestricted Access to Sensitive Business Flows, Server-Side Request Forgery, Unsafe Consumption of APIs and highlights emerging threats related to modern API architectures and integrations. For detailed information, please visit: OWASP API Security Top 10 - 2023. F5 products provide essential controls to secure APIs against these specific risks. F5 NGINX App Protect delivers comprehensive API security capabilities, employing both positive and negative security models. The positive security model validates API requests against defined schemas (like Open API) and enforces strict data formats, while the negative security model uses updated signatures to detect and block known API attack patterns and OWASP API Top 10 threats, including injection flaws and improper asset management. This guide outlines how to configure and implement effective protection for your APIs based on their specific requirements and the risks identified in the OWASP API Security Top 10. Note: The OWASP risks below are successfully tested on both NGINX App Protect Version 4 and Version 5. The set up and configurations for both the Versions are different. To bring up the setup for NGINX Version 5, follow the below links: https://docs.nginx.com/nginx-app-protect-waf/v5/admin-guide/install/ https://docs.nginx.com/nginx-app-protect-waf/v5/admin-guide/compiler/ API2:2023 – Broken Authentication Broken Authentication is a vulnerability that refers to incorrectly implemented authentication mechanisms or session management for APIs. Attackers exploit these flaws (like weak credentials, flawed token validation, or missing checks) to impersonate legitimate users and gain unauthorized access to data or functionality. Problem Statement: Broken Authentication is a big risk to API security. It happens when problems with the API’s identity verification process let attackers get around the authentication mechanisms. Successful exploitation leads attackers to impersonate legitimate users, gain unauthorized access to sensitive data, perform actions on behalf of victims, and potentially take over accounts or systems. This demonstration uses the Damn Vulnerable Web Application (DVWA) to show the exploitability of Broken Authentication. We will execute a brute-force attack against the login interface, iterating through potential credential pairs to achieve unauthorized authentication. Below is the selenium automated script to execute a brute-force attack, submitting multiple credential combinations to attempt authentication. The brute-force attack successfully compromised authentication controls by iterating through multiple credential pairs, ultimately granting access. Solution: To mitigate the above vulnerability, NGINX App Protect is deployed and configured as a reverse proxy in front of the application, and NAP first validates requests for the vulnerabilities. The NGINX App Protect Brute Force WAF policy is utilized as shown below. Re-attempt to gain access to the application using the brute-force approach is rejected and blocked. Support ID verification in the Security logs shows request is blocked because of Brute Force Policy. API3:2023 – Broken Object Property Level Authorization Broken Object Property Level Authorization is a key vulnerability listed that occurs when an API fails to properly validate if the current user has permission to access or modify specific fields (properties) within an object. This can lead to unauthorized data exposure or modification, even if the user has access to the object itself. This category combines API3: 2019 - Excessive Data Exposure and API6: 2019 - Mass Assignment. Excessive Data Exposure Problem Statement: A critical API security risk, Broken Authentication occurs when weaknesses in the API's identity verification process permit attackers to circumvent authentication mechanisms. Successful exploitation leads attackers to impersonate legitimate users, gain unauthorized access to sensitive data, perform actions on behalf of victims, and potentially take over accounts or systems. Solution: To prevent this vulnerability, we will use the DataGuard feature in NGINX App Protect, which validates all response data for sensitive details and will either mask the data or block those requests, as per the configured settings. First, we will configure DataGuard to mask the PII data as shown below and will apply this configuration. dataguard_blocking WAF Policy Next, if we resend the same request, we can see that the CCN/SSN numbers are masked, thereby preventing data breaches. If needed, we can update configurations to block this vulnerability, after which all incoming requests for this endpoint will be blocked. Fig: The request is blocked when block mode in blocking_settings is "true" If you open the security log and filter with this support ID, we can see that the request is either blocked or PII data is masked, as per the DataGuard configuration applied in the above section. Mass Assignment Problem Statement: API Mass Assignment vulnerability arises when clients can modify immutable internal object properties via crafted requests, bypassing API Endpoint restrictions. Attackers exploit this by sending malicious HTTP requests to escalate privileges, bypass security mechanisms, or manipulate the API Endpoint's functionality. Placing an order with quantity as 1: Bypassing API Endpoint restrictions and placing the order with quantity as -1 is also successful. Solution: To overcome this vulnerability, we will use the WAF API Security Policy in NGINX App Protect which validates all the API Security events triggered and based on the enforcement mode set in the validation rules, the request will either get reported or blocked, as shown below. Restricted/updated swagger file with .json extension is added as below: api.json file is updated with minimum Product Quantity Policy used: App Protect API Security Re-attempting to place the order with quantity as -1 is getting blocked. Attempt to place order with product count as -1 Validating the support ID in Security log as below: API4:2023 – Unrestricted Resource Consumption Unrestricted Resource Consumption refers to APIs that don't adequately limit the resources (e.g., CPU, memory, network bandwidth) a client can request or utilize. This can lead to performance degradation or Denial of Service (DoS) attacks, impacting availability for all users and potentially increasing operational costs significantly. Lack of Resources and Rate-Limiting Problem Statement: APIs do not have any restrictions on the size or number of resources that can be requested by the end user. The above-mentioned scenarios sometimes lead to poor API server performance, Denial of Service (DoS), and brute-force attacks. Solution: NGINX App Protect provides different ways to rate-limit the requests as per user requirements. A simple rate-limiting use case configuration can block requests after reaching the limit, which is demonstrated below. API6:2023 – Unrestricted Access to Sensitive Business Flows When an API lets people perform key business actions too easily without limits, attackers can automate abuse. This might mean hoarding products, causing financial damage, or spamming, giving them an unfair advantage. Problem Statement: Within the product purchasing flow, a critical vulnerability allows an attacker to execute a rapid, large-scale acquisition. They target a high-demand product, bypassing any intended quantity limits, and effectively corner the market by buying out the complete stock in one swift operation. This leaves genuine buyers frustrated and empty-handed, while the attacker capitalizes on the artificially created scarcity by reselling the goods at a steep markup. Below is the checkout POST call for the product. Below is the Python script to generate product checkout in bulk; provided quantity as 9999. Script to generate bulk product checkout requests Solution: The above vulnerability can be prevented using NGINX App Protect Bot Defense WAF Policy, which is blocking the bulk bot-generated product checkout request using the malicious script. Requests sent to check out the product using the above selenium script are blocked successfully as shown below. Bot request for bulk order is blocked Validating the support ID in Security log as below: Request captured in NGINX App Protect security log API7:2023 – Server-Side Request Forgery A new entrant to the OWASP API Security Top 10 in 2023, Server-Side Request Forgery (SSRF) vulnerabilities occur when an API fetches a remote resource (like a URL) without properly validating the user-supplied destination. Attackers exploit this by tricking the API into sending crafted requests to the server itself, leading to information disclosure or interaction with sensitive backend services. Problem Statement: Within the product purchasing flow, a critical vulnerability allows an attacker to execute a rapid, large-scale acquisition. They target a popular product, going past any planned limits, and effectively control the market by buying all the stock in one quick move. This makes real buyers angry and empty-handed, while the attacker makes money from the fake shortage by reselling the goods at a high price. In the application below, click on ‘Contact Mechanic’ and provide required details like Mechanic name, Problem Description and send Service Request. Contact Mechanic Request Payload 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. Exploiting the vulnerable endpoint by modifying ‘mechanic_api’ URL call to www.google.com in POST data call got accepted by returning 200 OK as response. This vulnerability can be misused to gain access to internal resources. POST Call with incorrect mechanic_api endpoint in request body Solution: To prevent this vulnerability, we will use the WAF API Security Policy in NGINX App Protect, which validates all the API request parameters and will block the suspicious requests consisting of irrelevant parameters, as shown below. Restricted/updated swagger file with .json extension is added as below: Updated the Swagger file with restricted pattern for mechanic_api endpoint Policy used: App Protect API Security API Security Policy Retrying the vulnerability with ‘mechanic_api’ URL call to www.google.com in POST data now getting blocked. mechanic_api endpoint in request body Validating the support ID in the security log below: API8:2023 – Security Misconfiguration Security problems happen when people don’t follow security best practices. This can lead to problems like open debug logs, old security patches, wrong CORS settings, and unnecessary allowed HTTP methods. To prevent this, systems must stay up to date with security patches, employ continuous hardening, ensure API communications use secure channels (TLS), etc. Problem Statement: Unnecessary HTTP methods/verbs represent a significant security misconfiguration under the OWASP API Top 10. APIs often reveal a range of HTTP methods (such as PUT, DELETE, PATCH) that are not required for the application's functionality. These unused methods, if not properly disabled, can provide attackers with additional attack surfaces, increasing the risk of unauthorized access or unintended actions on the server. Properly limiting and configuring allowed HTTP methods is essential for reducing the potential impact of such security vulnerabilities. Let’s dive into a demo application which has exposed “PUT” method., this method is not required as per the design and attackers can make use of this insecure, unintended method to modify the original content. modified using PUT method Solution: NGINX App Protect makes it easy to block unnecessary or risky HTTP methods by letting you customize which methods are allowed. By easily configuring a policy to block unauthorized methods, like disabling the PUT method by setting "$action": "delete", you can reduce potential security risks and strengthen your API protection with minimal effort. As shown below, the attack request is captured in security log, which conveys the request was successfully blocked because of “Illegal method” violation. API9:2023 – Improper Inventory Management Improper Asset Management in API security signifies the crucial risk stemming from an incomplete awareness and tracking of an organization’s full API landscape, including all environments like development and staging, different versions, both internal and external endpoints, and undocumented or "shadow" APIs. This lack of comprehensive inventory leads to an expanded and often unprotected attack surface, as security measures cannot be consistently applied to unknown or unmanaged assets. Consequently, attackers can exploit these overlooked endpoints, potentially find older, less secure versions or access sensitive data inadvertently exposed in non-production environments, thereby undermining overall security posture because you simply cannot protect assets you don't know exist. Problem Statement: APIs do not have any restrictions on the size or number of resources that can be requested by the end user. The above-mentioned scenarios sometimes lead to poor API server performance, Denial of Service (DoS), and brute-force attacks. We’re using a flask database application with multiple API endpoints for demonstration. As part of managing API assets, the “/v1/admin/users” endpoint in the demo Flask application has been identified as obsolete. The continued exposure of the deprecated “/v1/admin/users” endpoint constitutes an Improper Asset Management vulnerability, creating an unnecessary security exposure that could be used for exploitation. <public_ip>/v1/admin/users The current endpoint for user listing is “/v2/users”. <public_ip>/v2/users with user as admin1 Solution: To mitigate the above vulnerability, we are using NGINX as an API Gateway. The API Gateway acts as a filtering gateway for API incoming traffic, controlling, securing, and routing requests before they reach the backend services. The server’s name used for the above case is “f1-api” which is listening to the public IP where our application is running. To query the “/v1/admin/users” endpoint, use the curl command as shown below. Below is the configuration for NGINX as API Gateway, in “api_gateway.conf”, where “/v1/admin/users” endpoint is deprecated. api_gateway.conf The “api_json_errors.conf” is configured with error responses as shown below and included in the above “api_gateway.conf”. api_json_errors.conf Executing the curl command against the endpoint yields an “HTTP 301 Moved Permanently” response. https://f1-api/v1/admin/users is deprecated Conclusion: This article explains the OWASP 2023 Top 10 API security risks. It also shows how NGINX App Protect can be used to stop these OWASP API security risks. Related resources for more information or to get started: F5 NGINX App Protect OWASP API Security Top 10 2023Mitigating OWASP Web App Risks: Software and Data Integrity Failures using BIG-IP Advanced WAF
This article gives detailed information of OWASP top 10 Web Application security series, providing an in-depth knowledge on OWASP Software and Data Integrity attacks and mitigate methods using F5 BIG-IP Advanced WAF.
