Introduction 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: 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 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 balancerMitigating 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: 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 WAAPMitigating OWASP API Security Top 10 risks using F5 NGINX App Protect
This 2019 API Security article covers the summary of OWASP API Security Top 10 – 2019 categories and newly published 2023 API security article covered introductory part of newest edition of OWASP API Security Top 10 risks – 2023. 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. 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. 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. 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. 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/ Unrestricted Access to Sensitive Business Flows Problem Statement: By using the power of automation tools, attackers can now break through tough levels of protection. The inefficiency of APIs to detect automated bot tools not only causes business loss, but it can also adversely impact the services for genuine users of an application. Solution: NGINX App Protect has the best-in-class bot detection technology and can detect and label automation tools in different categories, like trusted, untrusted, and unknown. Depending on the appropriate configurations applied in the policy, requests generated from these tools are either blocked or alerted. Below is an example that shows how requests generated from the Postman automation tool are getting blocked. By filtering the security log with this support-id, we can see that the request is blocked because of an untrusted bot. 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. Server-Side Request Forgery Problem Statement: In an SSRF attack, vulnerable API endpoint within the application is targeted and attacker sends an unauthorized request allowing it to access internal resources. One of the common reasons for this is limited or lack of user input data validation. Example: In the demo application below, click on ‘Contact Mechanic’ and provide required details like Mechanic name, Problem Description and send Service Request. Below image shows that ‘contact_mechanic’ endpoint is internally making a call to ‘mechanic_api’ URL. Since ‘mechanic_api’ parameter accepts URL as data, this can be vulnerable to SSRF attacks. Exploiting the vulnerable endpoint by modifying ‘mechanic_api’ URL call to www.google.com in POST data call got accepted by returning 200 OK as response. This vulnerability can be misused to gain access to internal resources. Solution: To prevent this vulnerability, we will use the WAF API Security Policy in NGINX App Protect, which validates all the API request parameters and will block the suspicious requests consisting of irrelevant parameters, as shown below. Restricted/updated swagger file with .json extension is added as below: Policy used: App Protect API Security Retrying the vulnerability with ‘mechanic_api’ URL call to www.google.com in POST data now getting blocked. Validating the support ID in the security log below: 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: 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 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: 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: 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: Conclusion: CCN and SSN are sensitive information mapping to the identity of a specific individual and protecting this critical data is a necessity in this digital world. In this article we have demonstrated how F5 XC Distributed Cloud Platform can prevent these sensitive data exposures using data guard. 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 ShopMitigating 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-IPMitigating 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 Security
