Mitigation of OWASP API Security Risk: BOPLA using F5 XC Platform
Introduction: OWASP API Security Top 10 - 2019 has two categories “Mass Assignment” and “Excessive Data Exposure” which focus on vulnerabilities that stem from manipulation of, or unauthorized access to an object's properties. For ex: let’s say there is a user information in json format {“UserName”: ”apisec”, “IsAdmin”: “False”, “role”: ”testing”, “Email”: “apisec@f5.com”}. In this object payload, each detail is considered as a property, and so vulnerabilities around modifying/showing these sensitive properties like email/role/IsAdmin will fall under these categories. These risks shed light on the hidden vulnerabilities that might appear when modifying the object properties and highlighted the essence of having a security solution to validate user access to functions/objects while also ensuring access control for specific properties within objects. As per them, role-based access, sanitizing the user input, and schema-based validation play a crucial role in safeguarding your data from unauthorized access and modifications. Since these two risks are similar, the OWASP community felt they could be brought under one radar and were merged as “Broken Object Property Level Authorization” (BOPLA) in the newer version of OWASP API Security Top 10 – 2023. Mass Assignment: Mass Assignment vulnerability occurs when client requests are not restricted to modifying immutable internal object properties. Attackers can take advantage of this vulnerability by manually parsing requests to escalate user privileges, bypass security mechanisms or other approaches to exploit the API Endpoints in an illegal/invalid way. For more details on F5 Distributed Cloud mitigation solution, check this link: Mitigation of OWASP API6: 2019 Mass Assignment vulnerability using F5 XC Excessive Data Exposure: Application Programming Interfaces (APIs) don’t have restrictions in place and sometimes expose sensitive data such as Personally Identifiable Information (PII), Credit Card Numbers (CCN) and Social Security Numbers (SSN), etc. Because of these issues, they are the most exploited blocks to gain access to customer information, and identifying the sensitive information in these huge chunks of API response data is crucial in data safety. For more details on this risk and F5 Distributed Cloud mitigation solution, check this link: Mitigating OWASP API Security Risk: Excessive Data Exposure using F5 XC Conclusion: Wrapping up, this article covers the overview of the newly added category of BOPLA in OWASP Top 10 – 2023 edition. Finally, we have also provided minutiae on each section in this risk and reference articles to dig deeper into F5 Distributed Cloud mitigation solutions. Reference links or to get started: F5 Distributed Cloud Services F5 Distributed Cloud WAAP Introduction to OWASP API Security Top 10 2023Mitigating OWASP API Security Risk: Excessive Data Exposure using F5 XC Platform
This is part of the OWASP API Security TOP 10 mitigation series, and you can refer here for an overview of these categories and F5 Distributed Cloud Platform (F5 XC) Web Application and API protection (WAAP). Introduction to Excessive Data Exposure Application Programming Interfaces (APIs) are the foundation stone of modern evolving web applications which are driving the digital world. They are part of all phases in product development life cycle, starting from design, testing to end customer using them in their day-to-day tasks. Since they don't have restrictions in place, sometimes APIs expose sensitive data such as Personally Identifiable Information (PII), Credit Card Numbers (CCN) and Social Security Numbers (SSN), etc. Because of these issues, they are the most exploited blocks in cybercrime to gain access to customer information which can be sold or further used in other exploits like credential stuffing, etc. Most of the time, the design stage doesn't include this security perspective and relies on 3rd party tools to perform sanitization of the data before displaying the results to customers. Identifying the sensitive information in these huge chunks of API response data is sophisticated and most of the available security tools in the market don't support this capability. So instead of relying on third party tools it's recommended to follow shift left strategies and add security as part of the development phase. During this phase, developers must review and ensure that the API returns only required details instead of providing unnecessary properties to avoid sensitive data exposure. Excessive data exposure attack scenario-1 To showcase this category, we are exposing sensitive details like CCN and SSN in one of the product reviews of Juice shop application (refer links for more info) as below - Overview of Data Guard: Data Guard is F5 XC load balancer feature which shields the responses from exposing sensitive information like CCN/SSN by masking these fields with a string of asterisks (*). Depending on the customer's requirement, they can have multiple rules configured to apply or skip processing for certain paths and routes. Preventing excessive data exposure using F5 Distributed Cloud Step1: Create origin pool - Refer here for more information Step2: Create Web Application Firewall policy (WAF) - Refer here for details Step3: Create https load balancer (LB) with above created pool and WAF policy - Refer here for more information Step4: Upload your application swagger file and add it to above load balancer - Refer here for more details Step5: Configure Data Guard on the load balancer with action and path as below Step6: Validate the sensitive data is masked Open postman/browser, check the product reviews section/API and validate these details are hidden and not exposed as in original application In Distributed Cloud Console expand the security event and check the WAF section to understand the reason why these details are masked as below: Excessive data exposure attack scenario-2 In this demonstration we are using an API based vulnerable application VAmPI (VAmPI is a vulnerable API made with Flask, and it includes vulnerabilities from the OWASP top 10 vulnerabilities for APIs, for more info follow the repo link). Follow below steps to bring up the setup: Step1: Host the VAmPI application inside a virtual machine Step2: Login to XC console, create a HTTP LB and add the hosted application as an origin server Step3: Access the application to check its availability. Step4: Now enable API Discovery and configure sensitive data discovery policy by addingall the compliance frameworks in your HTTP LB config. Step5: Hit the vulnerable API Endpoint '/users/v1/_debug' exposing sensitive data like username, password etc. Step6: Navigate to security overview dashboard in the XC console and select the API Endpoints tab. Check for vulnerable endpoint details. Step7: In the Sensitive Data section, click Ellipsis on the right side to get options for action. Step8: Clicking on the option 'Add Sensitive Data Exposure Rule' will automatically add the entries for sensitive data exposure rule to your existing LB configs. Apply the configuration. Step9: Now again, hit the vulnerable API Endpoint '/users/v1/_debug' Here in the above image, you can see masked values in the response. All letters changed to 'a' and number is converted to '1'. Step10: Optionally you can also manually configure sensitive data exposure rule by adding details about the vulnerable API endpoint. Login back to XC console Start configuring API Protection rule in the created HTTP LB Click Configure in the Sensitive Data Exposure Rules section. Click Add Item to create the first rule. In the Target section, enter the path that will respond to the request. Also enter one or more methods with responses containing sensitive information. In the Values field in Pattern section, enter the JSON field value you want to mask. For example, to mask all emails in the array users, enter “users[_].email”. Note that an underscore between the square brackets indicates the array's elements. Once the above rule gets applied, values in the response will be masked as follows: All letters will change to a or A (matching case) and all numbers will convert to 1. Click Apply to save the rule to the list of Sensitive Data Exposure Rules. Optionally, Click Add Item to add more rules. Click Apply to save the list of rules to your load balancer. Step11: After the completion of Step10, Hit back the vulnerable API Endpoint. Here also in the above image, you can see masked values in the response as per the configurations done in Step 10. Conclusion As we have seen in the above use cases sensitive data exposure occurs when an application does not protect sensitive data like PII, CCN, SSN, Auth Credentials etc. Leaking of such information may lead to serious consequences. Hence it becomes extremely critical for organizations to reduce the risk of sensitive data exposure. As demonstrated above, F5 Distributed Cloud Platform can help in protecting the exposure of such sensitive data with its easy to use API Security solution offerings. For further information check the links below OWASP API Security - Excessive Data Exposure OWASP API Security - Overview article F5 XC Data Guard Overview OWASP Juice Shop VAmPIMitigating OWASP API Security Risk: Unrestricted Resource Consumption using F5 Distributed Cloud Platform
Introduction: Unrestricted Resource Consumption vulnerability occurs where an API allows end users to over-utilize resources (e.g., CPU, memory, bandwidth, or storage) without enforcing proper limitations. This can lead to overwhelming of the system, performance degradation, denial of service (DoS) or complete unavailability of the services for valid users. Attack Scenario: In this demo, we are going to generate huge traffic and observe the server’s behaviour along with its response time. Fig 1: Using Apache JMeter to send arbitrary number of requests to API endpoint continuously in very short span of time. Fig 2: (From left to right) Response time during normal and server with huge traffic. Above results show higher response time when abnormal traffic is sent to a single API endpoint when compared to normal usage. By further increases in volume, server can become unresponsive, deny requests from real users and result in DoS attacks. Fig 3: Attackers performing arbitrary number of API request to consume the server’s resources Customer Solution: F5 Distributed Cloud (XC) WAAP helps in solving above vulnerability in the application by rate limiting the API requests, thereby preventing complete consumption of memory, file system storage, CPU resources etc. This protects against traffic surge and DoS attacks. This article aims to provide F5 XC WAAP configurations to control the rate of requests sent to the origin server. Step by Step to configure Rate Limiting in F5 XC: These are the steps to enable Rate Limiting feature for APIs and its validation Add API Endpoints with Rate Limiter values Validation of request rate to violate threshold limit Verifying blocked request in F5 XC console Step 1: Add API Endpoints with Rate Limiter values Login to F5 XC console and Navigate to Home > Load Balancers > Manage > Load Balancers Select the load balancer to which API Rate Limiting should be applied. Click on the menu in Actions column of the app’s Load Balancer and click on Manage Configurations as shown below to display load balancer configs. Fig 4: Selecting menu to manage configurations for load balancer Once Load Balancer configurations are displayed, click on Edit configuration button on the top right of the page. Navigate to Security Configuration and select “API Rate Limit” in dropdown of Rate Limiting and click on “Add Item” under API Endpoint section. Fig 5: Choosing API Rate Limit to configure API endpoints. Fig 6: Configuring rate limit to API Endpoint Rate limit is configured to GET request from API Endpoint “/product/OLJCESPC7Z”. Click on Apply button displayed on the right bottom of the screen. Click on “Save and Exit” for above configuration to get saved to Load Balancer. Validation of request rate to violate threshold limit Fig 7: Verifying request for first time Request is sent for the first time after configuring API Endpoint and can be able to see the response along with status code 200. Upon requesting to the same API Endpoint beyond the threshold limit blocks the request as shown below, Fig 8: Rate Limiting the API request Verifying blocked request from F5 XC console From the F5 XC Console homepage, Navigate to WAAP > Apps & APIs > Security and select the Load Balancer. Click on Requests to view the request logs as below, Fig 9: Blocked API request details from F5 XC console You can see requests beyond the rate limiter value get dropped and the response code is 429. Conclusion: In this article, we have seen that when an application receives an abnormal amount of traffic, F5 XC WAAP protects APIs from being overwhelmed by rate limiting the requests. XC's Rate limiting feature helps in preventing DoS attacks and ensures service availability at all times. Related Links: API4:2019 Lack of Resources and Rate Limiting API4:2023 Unrestricted Resource Consumption Creating Load balancer Steps F5 Distributed Cloud Security WAAP F5 Distributed Cloud PlatformMitigating OWASP 2019 API Security Top 10 risks using F5 NGINX App Protect
This 2019 API Security article provides a valuable summary of the OWASP API Security Top 10 risks identified for that year, outlining key vulnerabilities. We will deep-dive into some of those common risks and how we can protect our applications against these vulnerabilities using F5 NGINX App Protect. API2:2019 - Broken User Authentication 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. This demonstration utilizes the Damn Vulnerable Web Application (DVWA) to illustrate 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 brute-force attack, submitting multiple credential combinations to attempt authentication. The brute-force attack successfully compromised the 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 reverse proxy in front of the application and requests are first validated by NAP 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. Request captured in NGINX App Protect security log API3:2019 - Excessive Data Exposure Problem Statement: As shown below in one of the demo application API’s, Personal Identifiable Information (PII) data, like Credit Card Numbers (CCN) and U.S. Social Security Numbers (SSN), are visible in responses that are highly sensitive. So, we must hide these details to prevent personal data exploits. 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. 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. 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. Request captured in NGINX App Protect security log API4:2019 - Lack of Resources & 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. 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 is able to block requests after reaching the limit, which is demonstrated below. API6:2019 - 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 event 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: Policy used: App Protect API Security Re-attempting to place the order with quantity as -1 is getting blocked. Validating the support ID in Security log as below: Request captured in NGINX App Protect security log API7:2019 - Security Misconfiguration Problem Statement: Security misconfiguration occurs when security best practices are neglected, leading to vulnerabilities like exposed debug logs, outdated security patches, improper CORS settings, unnecessary allowed HTTP methods, etc. To prevent this, systems must stay up to date with security patches, employ continuous hardening, ensure API communications use secure channels (TLS), etc. Example: Unnecessary HTTP methods/verbs represent a significant security misconfiguration under the OWASP API Top 10. APIs often expose 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. 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. Request captured in NGINX App Protect security log API8:2019 - Injection Problem Statement: Customer login pages without secure coding practices may have flaws. Intruders could use those flaws to exploit credential validation using different types of injections, like SQLi, command injections, etc. In our demo application, we have found an exploit which allows us to bypass credential validation using SQL injection (by using username as “' OR true --” and any password), thereby getting administrative access, as below: Solution: NGINX App Protect has a database of signatures that match this type of SQLi attacks. By configuring the WAF policy in blocking mode, NGINX App Protect can identify and block this attack, as shown below. App Protect WAF Policy If you check in the security log with this support ID, we can see that request is blocked because of SQL injection risk, as below. Request captured in NGINX App Protect security log API9:2019 - Improper Assets Management Problem Statement: 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. 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 leveraged 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. The “api_json_errors.conf” is configured with error responses as shown below and included in the above “api_gateway.conf”. Executing the curl command against the endpoint yields an “HTTP 301 Moved Permanently” response. https://f1-api/v1/admin/users is deprecated API10:2019 - Insufficient Logging & Monitoring Problem Statement: Appropriate logging and monitoring solutions play a pivotal role in identifying attacks and also in finding the root cause for any security issues. Without these solutions, applications are fully exposed to attackers and SecOps is completely blind to identifying details of users and resources being accessed. Solution: NGINX provides different options to track logging details of applications for end-to-end visibility of every request both from a security and performance perspective. Users can change configurations as per their requirements and can also configure different logging mechanisms with different levels. Check the links below for more details on logging: https://www.nginx.com/blog/logging-upstream-nginx-traffic-cdn77/ https://www.nginx.com/blog/modsecurity-logging-and-debugging/ https://www.nginx.com/blog/using-nginx-logging-for-application-performance-monitoring/ https://docs.nginx.com/nginx/admin-guide/monitoring/logging/ https://docs.nginx.com/nginx-app-protect-waf/logging-overview/logs-overview/ Conclusion: In short, this article covered some common API vulnerabilities and shows how NGINX App Protect can be used as a mitigation solution to prevent these OWASP API security risks. Related resources for more information or to get started: F5 NGINX App Protect OWASP API Security Top 10 2019 OWASP API Security Top 10 2023Mitigation of OWASP API Security Top 10 2023 using F5 Distributed Cloud Platform
The OWASP API Security project aims to help organizations by providing a guide with a list of the latest top 10 most critical API vulnerabilities and steps to mitigate them. As part of updating the old OWASP API Security risk categories for 2019, the OWASP API Security Top 10 2023 is released. List of vulnerabilities: API1:2023 Broken Object Level Authorization Broken Object Level Authorization (BOLA) is a vulnerability that occurs when there is a failure in validation of a user’s permissions to perform a specific task over an object, which may eventually lead to leakage, updation, or destruction of data. To prevent this vulnerability, proper authorization mechanisms should be followed, proper checks should be made to validate a user’s actions on a certain record, and security tests should be performed before deploying any production-grade changes. API2:2023 Broken Authentication Broken Authentication is a critical vulnerability that occurs when an application’s authentication endpoints fail to detect attackers impersonating someone else’s identity and allow partial or full control over the account. To prevent this vulnerability, observability and understanding of all possible authentication API endpoints is needed. Re-authentication should be performed for any confidential changes, multi-factor authentication, captcha-challenge, and effective security solutions should be applied to detect and mitigate credential stuffing, dictionary and brute-force types of attacks. Detailed explanation about the vulnerability with a demo showcasing the mitigation part using F5 Distributed Cloud can be found here API3:2023 Broken Object Property Level Authorization Broken Object Property Level Authorization is one of the new risk categories in the OWASP API Security Top 10 2023. This vulnerability occurs when a user is allowed to access an object’s property without validating their access permissions. Excessive Data Exposure and Mass Assignment which were initially a part of OWASP APISec 2019 are now part of this new vulnerability. To prevent this vulnerability, access privileges of users requesting for a specific object’s property should be scrutinized before exposure by the API endpoints. Use of generic methods and automatically binding client inputs to internal objects or code variables should be avoided and schema-based validation should be enforced. Detailed explanation about the vulnerabilities with demos showcasing the mitigation part using F5 Distributed Cloud can be found here (Excessive Data Exposure, Mass Assignment) API4:2023 Unrestricted Resource Consumption Unrestricted Resource Consumption vulnerability occurs when the system’s resources are being unnecessarily consumed, which could eventually lead to degradation of services and performance latency issues. Although the name has changed, the vulnerability is still the same as that of Lack of Resources & Rate Limiting. To prevent this vulnerability, rate-limiting, maximum size for input payload/parameters and server-side validations of requests should be enforced. Detailed explanation about the vulnerability with a demo showcasing the mitigation part using F5 Distributed Cloud can be found here API5:2023 Broken Function Level Authorization Broken Function Level Authorization occurs when vulnerable API endpoints allow normal users to perform administrative actions or a user from one group is allowed to access a function specific to users of another group. To prevent this vulnerability, access control policies and administrative authorization checks based on user’s group/roles should be implemented. API6:2023 Unrestricted Access to Sensitive Business Flows Unrestricted Access to Sensitive Business Flows is also a new addition to the list of API vulnerabilities. While writing API endpoints, it is extremely critical for developers to have a clear understanding of the business flows getting exposed by it. To avoid exposing any sensitive business flow and limit its excessive usage, which if not considered, might eventually lead to exploitation by the attackers and cause some serious harm to the business. This also includes securing and limiting access to B2B APIs that are consumed directly and often integrated with minimal protection mechanisms. By keeping automation to work, now-a-days, attackers can bypass traditional protection mechanisms. APIs inefficiency in detecting automated bot attacks not only causes business loss but also it can adversely impact the services for real users as well. To overcome this vulnerability, enterprises need to have a platform to identify whether the request is from a real user or an automated tool by analyzing and tracking patterns of usage. Device fingerprinting, Integrating Captcha solution, blocking Tor requests, are a few methods which can help to minimize the impact of such automated attacks. For more details on automated threats, you can visit OWASP Automated Threats to Web Applications Note: Although the vulnerability is new but it contains some references of API10:2019 Insufficient Logging & Monitoring Detailed explanation about the vulnerability with a demo showcasing the mitigation part using F5 Distributed Cloud can be found here API7:2023 Server-Side Request Forgery After finding a place in the OWASP Top 10 web application vulnerabilities of 2021, SSRF has now been included in the OWASP API Security Top 10 2023 list as well, showing the severity of this vulnerability. Server-Side Request Forgery (SSRF) vulnerability occurs when an API fetches an internal server resource without validating the URL from the user. Attackers exploit this vulnerability by manipulating the URL, which in turn helps them retrieve sensitive data from internal servers. To overcome this vulnerability, input data validations should be implemented to ensure that the client supplied input data obeys the expected format. Allow lists should be maintained so that only trusted requests/calls will be processed, and HTTP redirections should be disabled. Detailed explanation about the vulnerability with a demo showcasing the mitigation part using F5 Distributed Cloud can be found here API8:2023 Security Misconfiguration Security Misconfiguration is a vulnerability that may arise when security best practices are overlooked. Unwanted exposure of debug logs, unnecessary enabled HTTP Verbs, unapplied latest security patches, missing repeatable security hardening process, improper implementation of CORS policy, etc. are a few examples of security misconfiguration. To prevent this vulnerability, systems and entire API stack should be maintained up to date without missing any security patches. Continuous security hardening and configuration tracking process should be carried out. Make sure all API communications take place over a secure channel (TLS) and all servers in the HTTP server chain process incoming requests. Cross-Origin Resource Sharing (CORS) policy should be set up properly. Unnecessary HTTP verbs should be disabled. Detailed explanation about the vulnerability with a demo showcasing the mitigation part using F5 Distributed Cloud can be found here API9:2023 Improper Inventory Management Improper Inventory Management vulnerability occurs when organizations don’t have much clarity on their own APIs as well as third-party APIs that they use and lack proper documentation. Unawareness with regards to current API version, environment, access control policies, data shared with the third-party etc. can lead to serious business repercussions. Clear understanding and proper documentation are the key to overcoming this vulnerability. All the details related to API hosts, API environment, Network access, API version, Integrated services, redirections, rate limiting, CORS policy should be documented correctly and maintained up to date. Documenting every minor detail is advisable and authorized access should be given to these documents. Exposed API versions should be secured along with the production version. A risk analysis is recommended whenever newer versions of APIs are available. Detailed explanation about the vulnerability with a demo showcasing the mitigation part using F5 Distributed Cloud can be found here API10:2023 Unsafe Consumption of APIs Unsafe Consumption of APIs is again a newly added vulnerability covering a portion of API8:2019 Injection vulnerability. This occurs when developers tend to apply very little or no sanitization to data received from third-party APIs. To overcome this, we should make sure that API interactions take place over an encrypted channel. API data evaluation and sanitization should be carried out before using the data further. Precautionary actions should be taken to avoid unnecessary redirections by using Allow lists. Detailed explanation about the vulnerability with a demo showcasing the mitigation part using F5 Distributed Cloud can be found here Related OWASP API Security article series Broken Authentication Excessive Data Exposure Mass Assignment Lack of Resources & Rate limiting Security Misconfiguration Improper Assets Management Unsafe consumption of APIs Server-Side Request Forgery Unrestricted Access to Sensitive Business Flows OWASP API Security Top 10 - 2019Mitigating OWASP API Security risks using BIG-IP
The introduction article covered the summary of OWASP API Security TOP 10 categories. As part of this article, we will focus on how we can protect our applications against some of these vulnerabilities using F5 BIG-IP Advanced Web Application Firewall (AdvancedWAF). Excessive Data Exposure: Problem Statement: As shown below in one of the demo application API’s, Personally Identifiable Information (PII) data like Credit Card Numbers (CCN) and Social Security Numbers (SSN) are available which are highly sensitive and so we must hide these details to prevent personal data exploits. Solution: By configuring DataGuard related WAF settings in BIG-IP as below, we are able to mask these numbers thereby preventing data breaches. If needed, we can update settings to block this vulnerability after which all incoming requests for this endpoint will be blocked. Injection: Problem Statement: Customer login pages without secure coding practices may have flaws and intruders will use them to exploit credential validation using different types of injections like SQLi, Command Injections, etc. In our demo application, attackers were able to bypass validation using SQLi (Username as “' OR true --” and any password) thereby getting administrative access as below: Solution: By configuring AdvancedWAF settings in BIG-IP and by enabling appropriate violation blocking settings, we are able to identify and block these types of known injection attacks as below. Improper Assets Management: Problem Statement: In our demo application, attackers have identified deprecated endpoints with a path starting with “/v1” which are currently not being maintained but are still available. Using these undocumented endpoints, attackers can get access to unwanted data causing loss of sensitive app information. Solution: To avoid this specific use case, we have come up with OpenAPI or Swagger files for the demo application, uploaded them to BIG-IP and have configured AdvancedWAF to allow only these known URL’s. If attackers try to access deprecated URL’s which are not available in OpenAPI files, the requests will be blocked. Insufficient Logging & Monitoring: Problem Statement: Appropriate logging and monitoring solutions play a pivotal role in identifying attacks and also in finding the root cause for any security issues. Without these solutions, applications are fully exposed to attackers and are completely blind in identifying details of users and resources being accessed. Solution: BIG-IP provides many dashboards like Statistics, Dos Visibility, Analytics, OWASP, etc for end-to-end visibility of every request being accessed and users have the ability to filter requests as per their requirements. By default, system provides different types of logging profiles and users can also create custom logging profiles. They can attach them to Load Balancers to track these data flows. BIG-IP also supports a reporting service to generate the timely reports as needed by users. Conclusion: As demonstrated above, F5 BIG-IP AdvancedWAF can be used as a mitigation solution to prevent different OWASP security attacks against our modern applications running API’s. Stay tuned for more OWASP videos. For getting started, check below links: BIG-IP AdvancedWAF OWASP API Security Top 10 BIG-IP VE Overview of BIG-IPIntroduction to OWASP Top 10 API Security Risks - 2019 and F5 Distributed Cloud WAAP
Introduction to API: An application programming interface (API) is a combination of protocols, functions, etc. which we can utilize to get details about resources, services and features. APIs are fast, lightweight and reliable but they expose sensitive data and so they have become the targets of hackers. Overview of OWASP API Security: The simplicity of APIs has given hackers a chance to infiltrate them in plethora of ways to steal personal and sensitive details. Increase in demand of API security caused a need for a project to keep track of latest API vulnerabilities and security procedures called OWASP API Security Top 10. As per the above project below are the top ten issues and their overview in API security as of 2019. API1:2019 Broken Object Level Authorization APIs expose endpoints that manage objects using unique identifiers, providing hackers a chance to bypass access controls. To prevent this attacks authorized checks like credentials and API token should always be kept in place in the code if there is a request using a user input. API2:2019 Broken User Authentication Authentication mechanisms are sometimes implemented with less security, allowing attackers to compromise authentication tokens to take over other user's identities. For more information about this vulnerability, demonstration scenario and prevention steps using F5 XC refer to the article. API3:2019 Excessive Data Exposure In most of the recent attacks it was observed developers are exposing unnecessary and sensitive object properties providing illegal users a way to exploit them. For more information about this vulnerability, demonstration scenario and prevention steps using F5 XC refer to the article. API4:2019 Lack of Resources & Rate Limiting APIs do not have any restrictions on the size or number of resources that can be requested by the end user. Above mentioned scenarios sometimes lead to poor API server performance, Denial of Service (DoS) and brute force attacks. For more information about this vulnerability, demonstration scenario and prevention steps using F5 XC refer to the article. API5:2019 Broken Function Level Authorization Most applications are composed of different groups, users and roles. If configurations like access control are not applied, it will lead to authorization flaws allowing one user to access the resources of other users. API6:2019 Mass Assignment Code sanity should always be performed in response data, binding client data into code variables without filtering gives hackers a chance to guess object's properties by exploring the API endpoints, documentations, etc. For more information about this vulnerability, demonstration scenario and prevention steps using F5 XC refer to the article. API7:2019 Security Misconfiguration This attack is mostly caused because of misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages in logs containing sensitive information like usernames, PIN, IP addresses, etc. For more information about this vulnerability, demonstration scenario and prevention steps using F5 XC refer to the article. API8:2019 Injection OS commands, SQL, Command Injection, etc., occur if there are no restrictions on user requested schema as part of filter query. The malicious request can sometimes bypass these validations to execute unintended commands providing attackers access to sensitive information. For more information about this vulnerability, demonstration scenario and prevention steps using F5 XC refer to the article. API9:2019 Improper Assets Management A modern web application typically hosts thousands of requests. It is critical to update the documentation/swagger as per the latest changes and include information about newly implemented APIs. If they are not regularly updated hackers can explore and find any deprecated API which may sometimes expose debug endpoints. For more information about this vulnerability, demonstration scenario and prevention steps using F5 XC refer to the article. API10:2019 Insufficient Logging & Monitoring Any issues in logging and monitoring services will give attackers more ways to attack systems without being recognized. It’s always advised to configure the best monitoring solutions to keep track of all logs and to configure email alerts. Sometimes it’s the best practice to keep logging details in a different location to avoid malicious user activity erasing their log trails. For more information refer to the article. Overview of F5 Distributed Cloud WAAP: Web Application and API protection (WAAP) is a SAAS offering provided by F5 Distributed Cloud Services to protect applications and published APIs using Web Application Firewall (WAF), bot protection, API security, and DDoS mitigation. Once WAAP policy is applied on the load balancer, these service engines protect web applications and API endpoints with the latest automatic detection of WAF, Bot and DOS attack signatures. One of the key sections of Distributed Cloud WAAP is API security which focuses primarily on securing the API’s using different configurations like OpenAPI ingestion, automatic API discovery, service policies, rate limiting, Allow/Denied URLs, etc. Below diagram shows how Distributed Cloud WAAP protects APIs: Whenever there is a request originating from end users Distributed Cloud WAAP analyses the request metadata details like URL, filter parameters, Headers, etc. to find whether it’s a legitimate request. Once the request is screened, validated and approved then only the request is forwarded to the back-end servers. Back-end servers then return the requested details to the end user. If for any reason Distributed Cloud WAAP finds the request has discrepancies or is not valid the request will be blocked, and a security event will be generated in dashboard. Users or administrators can analyze the captured request details and can modify the existing Distributed Cloud WAAP configurations if needed to reach the business goals. Articles on OWASP API Security: Broken User Authentication Excessive Data Exposure Lack of Resources & Rate Limiting Mass Assignment Security Misconfiguration Injection Improper Assets Management Insufficient Logging & Monitoring Note: Articles on remaining OWASP API Security Top 10 2019 vulnerabilities are in pipeline and will get published shortly, stay tuned for the update New edition of OWASP API Security Top 10 risks - 2023 is released and you can check this link for more details Related Links: F5 Distributed Cloud WAAP F5 Distributed Cloud ServicesMitigating 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. 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. 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. Cross-Origin responds back with Preflight Response where it’s allowing all the requests. Browser checks the preflight response and since all the requests are allowed, actual request containing the payload is sent to the cross-origin. 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. Prevention using F5 XC: From the suite of security solutions offered by F5 Distributed Cloud(XC) WAAP, here we have chosen to create an ‘CORS Policy’ to allow only authorized requests. Pre-requisites: Create a Load Balancer in F5 XC and point the LB to the vulnerable web server by adding the server details in origin pool. For LB configuration steps, please follow the steps here. Configure CORS policy under “Common Security Controls” in LB to allow only authorized requests. For CORS configuration steps, please follow the steps here. *Allow Origin and Allow Origin Regex fields in F5 XC CORS configuration will be used to verify the Origins for CORS. Origins/Domains not listed won’t be blocked and continue to work normally. Note – Chrome browser is used throughout this demo The malicious activity which can be performed in the scenario discussed earlier can be mitigated by having the vulnerable cross-origin web server behind F5 XC . In F5 XC load balancer a CORS feature security policy must be configured to check origin, methods and customer headers based on security requirement. 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. 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. Fig 2.2 - Preflight request Highlighted sections will be part of Preflight Request sent to the cross-origin (target server) from the web browser. These values are extracted from the request made by the user. Since cross-origin is protected by F5 XC in this scenario, F5 XC responds with Preflight Response. Fig 2.3 - Preflight response As per our architecture shown in Fig 2, cross-origin (target server) is behind F5 XC which has a CORS policy configured. The highlighted section shows the Preflight Response sent from the F5 XC to the web browser based on the CORS configuration defined in F5 XC. The browser checks the preflight response sent from the F5 XC where all the non-simple methods and custom headers are blocked, web browser verifies this and drops the actual request. Fig 2.4 - Actual request blocked due to CORS Fig 2.5 - Preflight options call captured in F5 XC In the above screenshot, Preflight (OPTIONS) request made to load balancer (having target server) can be observed. The subsequent actual request is not present which is blocked by the browser based on CORS configuration. Conclusion In conclusion, ensuring that web applications are safeguarded against CORS vulnerabilities is not just a technical necessity—it's a critical step in protecting users and business. By using F5 XC WAAP solution, proactive control can be taken over security environment, preventing unauthorized cross-origin requests and safeguarding sensitive data from malicious actors. Further Reading Official W3C CORS specification CORS Reference OWASP API Security Project OWASP API7:2019 Security Misconfiguration F5 Distributed Cloud Services F5 Distributed Cloud WAAP Overview of OWASP API Security Top 10 2019Mitigation of OWASP API Security Risk: Unsafe Consumption of API using F5 XC Platform
Introduction: The Introductory article covered a brief overview of OWASP Top 10 API Security risk/vulnerability. This article is a continuation of the series and shows mitigating API Vulnerability Unsafe Consumption of API using F5 Distributed Cloud (F5 XC) WAAP. See F5 Distributed Cloud API Security in action. Problem Description: The Digital transformation and modernization of Apps is accelerating to meet the market demands, which results in proliferation of architecture in data center, private/public cloud and across multi cloud which results in organizations to scramble and to gain the competitive edge. As Apps modernization involves API-based systems, those endpoints are now distributed across multiple environments, including third-party services. These third-party APIs are exposing new security risks due to interaction with them. These endpoints are trusted and not verified due to. Developers tend to adopt weaker security standards for authentication/authorization, input validation and sanitization, thereby making these APIs attractive to attackers. Solution from F5 XC: F5 XC delivers a broad approach to API security with a combination of management, monitoring/visibility, and enforcement functionalities. This allows organizations to discover third-party API endpoints, their request/response schemas, sensitive data, authentication state easily and effectively. F5 XC helps in monitoring and securing these API endpoints by performing continuous learning and inspection to provide protection against malicious users. This article aims to demonstrate validation and sanitization of data received from the third-party integrated API before processing further. Preventing unsafe consumption of API vulnerabilities using F5 XC SaaS console configs: Below are the steps that are being followed to access valid API data from the third-party Integrated API, Upload the modified swagger file Configure API Protection for Endpoints Step 1: Uploading the modified swagger file We are updating the swagger file to define API groups and set rules to control access to APIs, enabling granular API access control ability. This ensures traffic from a third-party API complies with the specified schema. If the traffic does not conform to the API schema of third-party services, you can enable action to block the traffic, ensuring the security and integrity of your API. Note: In this case, Endpoints and expected data associated to it in the Swagger file is validated properly by the developers before uploading in F5 XC console. Login to F5 XC console and click on Multi-cloud App Connect. Select the HTTP Load Balancer by selecting “…” > Manage configuration for your load balancer to which API Protection to be enabled. Select Edit Configuration on the manage configuration screen. Go to API Protection section, From the API definition menu, select Enable to use an API definition. From the API Definition menu, select the API definition. Click “Add Item” to create a new definition. Enter name in metadata section. In Swagger Specs section, click on the drop-down menu and select “Upload Swagger file”. Enter the name in Metadata section of Swagger File. Click on Upload File button in Swagger Upload section to upload the swagger file. A sample swagger file shown below validates the email address returned by the third-party server. Once the file is uploaded, click on Continue. Select the swagger file created above from the Swagger Specs drop-down and click on Continue and page will be redirected to LB configuration page. Step 2: Configuring API Protection for Endpoints From Validation drop-down, select “All Endpoints” to enable validation for all the endpoints specified in the swagger file. In the “All endpoints” validation section, From the OpenAPI Validation Response Processing Mode menu, select validate. From the Response Validation Enforcement Type menu, select the type of enforcement as Block. From the Response Validation Properties menu, select HTTP Headers, Content-type, HTTP Body, and Response Code. Enable Show Advanced Fields button on the top right corner of the section and select Property Validation Settings to Custom and select “Disallow” for Allow/Disallow additional query parameters in Request. Click on Apply. Click on Save and Exit. In this scenario, below is the data sent by the third-party API to store the details in the database server If the third-party service returns data, which includes malicious SQL injection/payload that causes harm to the database servers during the process of transport security, authentication/authorization. In this attack scenario, a third-party API returns data consisting of 'Admin' OR 1=1--' which tries to compromise the system. This is instantly identified, cautioned, and mitigated by F5 XC. Json data logs for respective security analytics. Conclusion: With F5 XC things become easier to manage, monitor and enforce security to API services. F5 XC provides the feasibility of continuous discovery of APIs and inspecting data received from the third-party services when configured appropriately in the Load Balancer. This helps in secure and manage APIs with the modern App and API deployment with necessary management and protection against threats. Related Links: https://owasp.org/API-Security/editions/2023/en/0xaa-unsafe-consumption-of-apis/ https://docs.cloud.f5.com/docs/how-to/app-security/apiep-discovery-control https://docs.cloud.f5.com/docs/how-to/app-networking/http-load-balancer Introduction to OWASP API Security Top 10 2023
