Mitigating 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 2023Mitigating OWASP API Security Risk: Mass Assignment 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 Mass Assignment using F5 Distributed Cloud Platform (XC). Introduction to OWASP API Mass Assignment: APIs are the foundation building blocks for today’s modern applications and because of such high acceptance there are software frameworks available to help the developers with the implementation, but these frameworks sometimes allow developers to automatically bind client’s request parameters into the code variables, opening gates for the attackers to exploit the Mass Assignment vulnerability. API Mass Assignment vulnerability occurs when manually crafted requests from clients to modify immutable internal object properties are not restricted by API Endpoints. Attackers can take advantage of this vulnerability by framing an HTTP request to escalate user privilege, bypass security mechanisms or use any other approach to make the API Endpoints work in a way it was not designed to work. Note: Mass Assignment and Excessive Data Exposure which were a separate risk category in OWASP API Sec 2019 are now merged into a new risk category named Broken Object Property Level Authorization The above image is the pictorial representation of possible exploitation of Mass Assignment vulnerability. You can see the attacker is successfully able to escalate his privilege from normal user to admin by manipulating the JSON content of the API request. In the first step, the attacker sends a valid API request to add the user and gets a response back with a parameter carrying information about the role. In the second step, the attacker adds the role parameter to the JSON object in the API request eventually resulting in successful exploitation of the vulnerability. Prevention Steps: Automatic binding of client’s input data into application's internal code variables should be avoided. Allow/Deny list should be clearly defined for the properties that should or shouldn't be accessible by the clients. Application schema should be well defined and enforced on all incoming client requests. Demonstration: For this demonstration we’ve already hosted crAPI (completely ridiculous API) application by referring to the QuickStart guide in the repository. Also, in the XC console we added the hosted application as an origin server and attached it with the newly created HTTP Load Balancer (LB). 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 Attack Scenario: In the use case below we have an API endpoint which is used to order products. This endpoint has a vulnerable field named “quantity” that can be exploited for mass assignment by providing a negative value resulting in a successful purchase order with an increase in available balance. As shown below at the start of the demo, the available balance for a user account is 200 $. Step1: First step is to gather the endpoint and request payload data by placing a valid purchase order from GUI. In the above screenshot, you can see we have successfully placed the order from the GUI which resulted in a decrease of available balance by 10$. This is a valid customer use case scenario. Step2: Next, we will try to place an order for a product with negative quantity using the gathered endpoint and check if mass assignment vulnerability is present or not. As you can see in the above screenshot the order with the negative quantity is placed successfully and the available balance is increased by 10$ which is not expected. Hence, we can conclude that mass assignment vulnerability exists in this demo application. Prevention through F5 XC: As mentioned in the prevention steps for the purpose of schema validation we will upload OpenAPI specification file to XC and set up the validation rules on incoming client requests If a mismatch occurs, an API Security event will be triggered and based on the enforcement mode set in the validation rules, the request will either get reported or blocked. Step1: As shown in the below image, update the crAPI’s OpenAPI specification file (a.k.a. swagger file) by adding a “minimum” keyword with value as “1” for the “quantity” parameter to restrict the request carrying a negative quantity to bypass Step2: Import crAPI’s swagger file to the LB and create API Definitions Login to F5 XC console Navigate to your LB and start editing the applied configuration Scroll down to API Protection and select “Enable” in API Definition field Click “Add Item”, Enter a name Click “Upload Swagger file”, Enter a name and upload the swagger file for your application, Apply the changes Now from your LB main config page, select “Custom List” for “Validation” field and click Configure. Start configuring Validation List, click “Add Item”, Enter a name, 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, below of the config page select “Base Path - /” for “Type” field, Apply the changes. Refer to the document for more details. Step3: Try to repeat the attack scenario of ordering a product with negative quantity. As you can see in the above screenshot the attack was blocked successfully by the XC. Step4: Monitor the “Security Analytics” logs from F5 XC console Conclusion: API Mass assignment vulnerability can illegally be exploited by attackers to cause some serious damage but as demonstrated, F5 XC API security solutions can help to detect and mitigate such vulnerabilities with the help of Open-API schema validation feature. For more details, follow below links: OWASP API Security Project OWASP API6:2019 Mass Assignment F5 Distributed Cloud Services F5 Distributed Cloud WAAP Overview of OWASP API Security Top 10 2019 Introduction to OWASP API Security Top 10 2023Mitigating 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-IPMitigation of OWASP API Security Risk: Broken Authentication using F5 XC Platform
Introduction to Broken Authentication: Authentication in APIs adds friction, so during the initial development phase and for the sake of simplicity developers try to not implement authentication and authorization processes. As the application keeps growing, they will add these recommendations to existing code and during this transition they may have left some of the old internal APIs without authentication. Hackers will try to find these kinds of poorly authenticated flaws to bypass the login validation and gain access to their application data. According to Okta, most of the data breaches in 2020 fall under this category and so this is one of the most preferred approaches to attackers. Authentication is said to be broken if hackers are able to compromise passwords, keys, session tokens and user account information. As per OWASP, APIs may fall under this category if API doesn’t have authentication validation API permits credential stuffing API permits attackers to perform a brute force attack without presenting captcha/account lockout mechanism Permits weak passwords Sends sensitive authentication details, such as auth tokens and passwords in the URL Strong password policy not implemented Below are some of the preventive measures which are to be followed to protect application from these kinds of exploits: Authentication support for all API’s Authorization design developed in a good and structured way using access controls Session tokens need to be expired in shorter time Rate limiting and account locking after specific invalid logins Rotation of keys and certs Internal APIs should be audited and not exposed to outside Multi factor authentication support for critical APIs Enforcing strong password policy with special chars, capitals, numbers and minimum of 8 characters length In short, if the application doesn’t have authentication mechanism, supports weak passwords or even if we are unable to identify the authentication details of our requests, our application can be prone to broken authentication. And to prevent this risk we need different kinds of solutions to identify authentication details, enforce authentication policies, prevent credential stuffing & bot attacks, continuous monitoring of API’s, etc. So, let’s delve into F5 Distributed Cloud Platform (XC) and check how it can detect and protect applications against these vulnerabilities. Authentication Vulnerabilities Detection: Login to Distributed Cloud console and navigate to your load balancer configuration Enable API Discovery feature on this load balancer Once we have enabled this feature, Web Application and API Protection (WAAP) inbuilt AI/ML engine will start tracking all incoming traffic and after some time we will be able to see API endpoint details as below Change to table view and observe different types of authentication details along with some of the vulnerabilities discovered by WAAP as below a. API type and authentication state b. Auth type like JWT and insights on user role c. Security assessment for API endpoint vulnerabilities, threat level and risk score d. Sensitive data leakage like IP, credentials, etc Mitigation Steps: AppSec/SecOps can navigate to the Security & API endpoint dashboards and analyze these requests data & authentication insights. If they are not familiar with any kind of requests, they can explore the solutions below and as per their requirements they can configure them to prevent these vulnerabilities. Configure rate limiting to keep a limit on number of requests - check here for more details on rate limiting Configure API Protection rules on load balancer to restrict access to applications – check here for more details on API rules Configure Bot Defense to prevent credential stuffing and bot attacks – check here for more details on bot protection Configure OpenAPI schema validation to detect/block invalid and abnormal requests – for more details check this article Malicious user detection – check this existing article for more details Configure Mutual Transport Layer Security (mTLS) authentication using client certificates - check here for more information Conclusion: Wrapping up, this article covered an overview of broken authentication risk and then we also shed light on how WAAP can extract valuable authentication vulnerabilities. Lastly, we also discussed some of the XC mitigation steps to prevent this API Security risk. For more information or to get started check links below: OWASP API Security Top 10 2019 OWASP API Security Top 10 2023 F5 Distributed Cloud WAAPIntroduction 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 ServicesMitigation 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: Improper Assets Management using F5 XC Platform
Overview: In the introductory article and subsequent series (overview) we have demonstrated how F5 Distributed Cloud Web App and API Protection (WAAP) has prevented OWASP Top 10 API Security risk categories of 2019 with demonstration. This article is the continuation of this series, demonstrating how to mitigate Improper Assets Management vulnerabilities using F5 Distributed Cloud Platform. Introduction to Improper Assets Management: A vulnerability that appears when multiple services are left over to an old API version, unprotected, giving access to the attackers to get the sensitive information from the application database. Architecture: Problem statement: Modern applications require fast iteration through the development cycle and sometime old artifacts, such as APIs, are not properly phased out. For example, while the new API (app.service.com/v2) is created, the old API (app.service.com/v1/admin) is deprecated but still available and unprotected by a WAF, provides access to the attacker to get sensitive information of database. Solution: In this demonstration, we will see how F5 XC helps to patch the above vulnerability and protect the overlooked, unprotected older versions of APIs (Application Programming Interfaces) from the attackers. Mitigation steps using F5 XC: Here is the procedure to configure API Protection rules in the load balancer and associate the LB (Load Balancer) to the origin pool (backend application – app.service.com). Create origin pool Refer pool-creation for more info. Create http load balancer (LB) and associate the above origin pool to it. Refer LB-creation for more info . Configure API Protection Rules under load balancer and add the Server URLs and API Groups. Navigate to the load balancer--> API Protection--> configure API Protection Rules. Click on ”Edit Configuration“ under Server URLs and API Groups. Add an item, give rule name, action, base path. Click on “apply”. Click on “Save and Exit” to save the Load Balancer configuration. Try to access the endpoint through LB domain with v1 version. Try to access the endpoint through LB domain with v2 version. Validate the logs through F5 XC. Navigate to WAAP --> Apps & APIs --> Security Dashboard, select your LB and click on ‘Security Event’ tab. Above screenshot gives the detailed policy information on how F5 XC WAAP is detecting and blocking the attacks based on the configuration under LB --> API Protection Rules --> Base Path. Conclusion: As you can see from the demonstration, the F5 Distributed Cloud WAAP has successfully able to detect and mitigate the vulnerabilities on API endpoints using API protection rules. For further information click the links below: F5 Distributed Cloud WAAP F5 Distributed Cloud Services OWASP API SecurityMitigating 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: Injection flaws using F5 XC Platform
Overview of OWASP and F5 Distributed Cloud Web Application and API Protection: The Introductory article covered basics of OWASP and API Security. We have also seen summary of the top 10 vulnerabilties and an overview of F5 Distributed Cloud (F5 XC) Web Application and API Protection (WAAP). This article is in continuation of the series and shows a scenario of how we can mitigate Injection attack using F5 XC. Introduction to Injection: An injection attack is facilitated by a vulnerability which allows a hacker to provide some malicious code to the application in an unexpected way. When an application passes information from user input, as a best practice there should be some validations in place before sending request to the back-end servers. Sometimes an attacker can induce special characters (like $ to get env variable) and malicious code to bypass the scope and get sensitive details. Some of these attacks include: Executing Linux system calls on back-end servers to get sensitive information Allowing an attacker to steal other user tokens, session cookies, etc. Running malicious scripts like Cross Site Scripting Introduction to F5 Distributed Cloud Web Application Firewall: Most of these exploits can be blocked using F5 Distributed Cloud Web Application Firewall (F5 XC WAF) which supports a vast variety of these types of signatures categorized as LOW, MEDIUM and HIGH. F5 XC WAF can be configured with simple default configuration and can be tuned to custom attack signatures at lowest level. If needed, customers can also explore security events, research attack signatures to identify if the request is valid or illegal and whether it should be blocked or allowed. After analyzing these security events, administrators/SecOps can go ahead and further tune existing WAF configuration as per their business needs. Problem statement: Below demo shows a simple application login API using Postman tool and how we can prevent injection attacks on this API using F5 XC WAF. First let’s analyze the login API of a demo application. As part of the request, the payload takes 2 parameters and users provide a valid username and password to authenticate the login successfully. Valid Postman Request: Illegal Postman Request using SQL Injection: If the application code is not sanitized and validated, then attackers can explore the SQL query used in the request and can add malicious SQL commands (For ex: inject OR 1=1 in the query which is always true and returns data) thereby bypassing the credential validation and can login to application as below. Prevention: We can protect our web applications by creating load balancer and applying F5 XC WAF as below: Login to F5 Distributed Cloud Console with your credentials Navigate to Load balancers menu, then expand “Security” section and then click on “App Firewall” Create App Firewall with mode as Blocking (refer links for more details) Navigate to Manage section and from drop-down select “HTTP Load Balancers” Create load balancer and apply above created App Firewall (refer links for more details) Open Postman and try to regenerate SQL injection attack with same code provided above Validate your request is blocked as below: In Distributed Cloud Console navigate to security events section, expand the latest requests and filter logs with your request-ID. As shown below we can see request is blocked because of SQL Injection vulnerability: Conclusion: As demonstrated above, F5 Distributed Cloud WAAP can be used to detect, alert and mitigate Injection vulnerabilities. Related Links: F5 Distributed Cloud Platform F5 Distributed Cloud Security WAAP Creating Load balancer Steps Security WAAP features of load balancer
