Mitigating 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-IPF5 Distributed Cloud Bot Defense (Overview and Demo)
What is Distributed Cloud Bot Defense? Distributed Cloud Bot Defense protects your web properties from automated attacks by identifying and mitigating malicious bots. Bot Defense uses JavaScript and API calls to collect telemetry and mitigate malicious users within the context of the Distributed Cloud global network. Bot Defense can easily be integrated into existing applications in a number of ways. For applications already routing traffic through Distributed Cloud Mesh Service, Bot Defense is natively integrated into your Distributed Cloud Mesh HTTP load balancers. This integration allows you to configure the Bot Defense service through the HTTP load balancer's configuration in the Distributed Cloud Console. For other applications, connectors are available for several common insertion points that likely already exist in modern application architectures. Once Bot Defense is enabled and configured, you can view and filter traffic and transaction statistics on the Bot Defense dashboard in Distributed Cloud Console to see which users are malicious and how they’re being mitigated. F5 Distributed Cloud Bot Defense is an advanced add-on security feature included in the first launch of the F5 Web Application and API Protection (WAAP) service with seamless integration to protect your web apps and APIs from a wide variety of attacks in real-time. High Level Distributed Cloud Security Architecture Bot Defense Demo: In this technical demonstration video we will walk through F5 Distributed Cloud Bot Defense, showing you how quick and easy it is to configure, the insights and visibility you have while demonstrating a couple of real attacks with Selenium and Python browser automation. "Nature is a mutable cloud, which is always and never the same." - Ralph Waldo Emerson We might not wax that philosophically around here, but our heads are in the cloud nonetheless! Join the F5 Distributed Cloud user group today and learn more with your peers and other F5 experts. Hope you enjoyed this Distributed Cloud Bot Defense Overview and Demo. If there are any comments or questions please feel free to reach us in the comments section. Thanks! Related Resources: Deploy Bot Defense on any Edge with F5 Distributed Cloud (SaaS Console, Automation) Protecting Your Web Applications Against Critical OWASP Automated Threats Making Mobile SDK Integration Ridiculously Easy with F5 XC Mobile SDK Integrator JavaScript Supply Chains, Magecart, and F5 XC Client-Side Defense (Demo) Bots, Fraud, and the OWASP Automated Threats Project (Overview) Protecting Your Native Mobile Apps with F5 XC Mobile App Shield Enabling F5 Distributed Cloud Client-Side Defense in BIG-IP 17.1 Bot Defense for Mobile Apps in XC WAAP Part 1: The Bot Defense Mobile SDK F5 Distributed Cloud WAAP Distributed Cloud Services Overview Enable and Configure Bot Defense - F5 Distributed Cloud ServiceIntroduction to OWASP API Security Top 10 2023
Introduction to API An Application Programming Interface (API) is a component that enables communication between two different systems by following certain rules. It also adds a layer of abstraction between the two systems where the requester does not know how the other system has derived the result and responded back. Over the past few years, developers have started relying more on APIs as it helps them to meet the needs of today’s rapid application deployment model. As the APIs started getting a wider acceptance it is highly critical to safeguard them by thoroughly testing their behavior and following best security practices. Learn API Security Best Practices. Overview of OWASP API Security The OWASP API Security project aims to help the organizations by providing a guide with a list of the latest top 10 most critical API vulnerabilities and steps to mitigate them. As part of updating the old OWASP API Security risk categories of 2019, recently OWASP API Security Top 10 2023 is released. What’s new in OWASP API Sec 2023? List of vulnerabilities: API1:2023 Broken Object Level Authorization Broken Object Level Authorization (BOLA) is a vulnerability that occurs when there is a failure in validation of user’s permissions to perform a specific task over an object which may eventually lead to leakage, updation or destruction of data. To prevent this vulnerability, proper authorization mechanism should be followed, proper checks should be made to validate user’s action on a certain record and security tests should be performed before deploying any production grade changes. API2:2023 Broken Authentication Broken Authentication is a critical vulnerability that occurs when application’s authentication endpoints fail to detect attackers impersonating someone else’s identity and allow partial or full control over the account. To prevent this vulnerability, observability and understanding of all possible authentication API endpoints is needed, re-authentication should be performed for any confidential changes, multi-factor authentication, captcha-challenge and effective security solutions should be applied to detect & mitigate credential stuffing, dictionary and brute force type of attacks. API3:2023 Broken Object Property Level Authorization Broken Object Property Level Authorization (Excessive Data Exposure, Mass Assignment) is one of the new risk categories of OWASP API Security Top 10 2023. This vulnerability occurs when a user is allowed to access an object’s property without validating his access permissions. Excessive Data Exposure and Mass Assignment which were initially a part of OWASP APISec 2019 are now part of this new vulnerability. To prevent this vulnerability, access privileges of users requesting for a specific object's property should be scrutinized before exposure by the API endpoints. Use of generic methods & automatically binding client inputs to internal objects or code variables should be avoided and schema-based validation should be enforced. API4:2023 Unrestricted Resource Consumption Unrestricted Resource Consumption vulnerability occurs when the system’s resources are being unnecessarily consumed which could eventually lead to degradation of services and performance latency issues. Although the name has changed, the vulnerability is still the same as that of Lack of Resources & Rate Limiting. To prevent this vulnerability, rate-limiting, maximum size for input payload/parameters and server-side validations of requests should be enforced. API5:2023 Broken Function Level Authorization Broken Function Level Authorization occurs when vulnerable API endpoints allow normal users to perform administrative actions or user from one group is allowed to access a function specific to users of another group. To prevent this vulnerability, access control policies and administrative authorization checks based on user’s group/roles should be implemented. API6:2023 Unrestricted Access to Sensitive Business Flows Unrestricted Access to Sensitive Business Flows is also a new addition to the list of API vulnerabilities. While writing API endpoints it is extremely critical for the developers to have a clear understanding of the business flows getting exposed by it. To avoid exposing any sensitive business flow and limit its excessive usage which if not considered, might eventually lead to exploitation by the attackers and cause some serious harm to the business. This also includes securing and limiting access to B2B APIs that are consumed directly and often integrated with minimal protection mechanism. By keeping automation to work, now-a-days attackers can bypass traditional protection mechanisms. APIs inefficiency in detecting automated bot attacks not only causes business loss but also it can adversely impact the services for real users as well. To overcome this vulnerability, enterprises need to have a platform to identify whether the request is from a real user or an automated tool by analyzing and tracking patterns of usage. Device fingerprinting, Integrating Captcha solution, blocking Tor requests, are a few methods which can help to minimize the impact of such automated attacks. For more details on automated threats, you can visit OWASP Automated Threats to Web Applications Note: Although the vulnerability is new but it contains some references of API10:2019 Insufficient Logging & Monitoring API7:2023 Server-Side Request Forgery After finding a place in OWASP Top 10 web application vulnerabilities of 2021, SSRF has now been included in OWASP API Security Top 10 2023 list as well, showing the severity of this vulnerability. Server-Side Request Forgery (SSRF) vulnerability occurs when an API fetches an internal server resource without validating the URL from the user. Attackers exploit this vulnerability by manipulating the URL, which in turn helps them to retrieve sensitive data from the internal servers. To overcome this vulnerability, Input data validations should be implemented to ensure that the client supplied input data obeys the expected format. Allow lists should be maintained so that only trusted requests/calls will be processed, and HTTP redirections should be disabled. API8:2023 Security Misconfiguration Security Misconfiguration is a vulnerability that may arise when security best practices are overlooked. Unwanted exposure of debug logs, unnecessary enabled HTTP Verbs, unapplied latest security patches, missing repeatable security hardening process, improper implementation of CORS policy etc. are a few examples of security misconfiguration. To prevent this vulnerability, systems and entire API stack should be maintained up to date without missing any security patches. Continuous security hardening and configurations tracking process should be carried out. Make sure all API communications take place over a secure channel (TLS) and all servers in HTTP server chain process incoming requests. Cross-Origin Resource Sharing (CORS) policy should be set up properly. Unnecessary HTTP verbs should be disabled. API9:2023 Improper Inventory Management Improper Inventory Management vulnerability occurs when organizations don’t have much clarity on their own APIs as well as third-party APIs that they use and lack proper documentation. Unawareness with regards to current API version, environment, access control policies, data shared with the third-party etc. can lead to serious business repercussions. Clear understanding and proper documentation are the key to overcome this vulnerability. All the details related to API hosts, API environment, Network access, API version, Integrated services, redirections, rate limiting, CORS policy should be documented correctly and maintained up to date. Documenting every minor detail is advisable and authorized access should be given to these documents. Exposed API versions should be secured along with the production version. A risk analysis is recommended whenever newer versions of APIs are available. API10:2023 Unsafe Consumption of APIs Unsafe Consumption of APIs is again a newly added vulnerability covering a portion of API8:2019 Injection vulnerability. This occurs when developers tend to apply very little or no sanitization on the data received from third-party APIs. To overcome this, we should make sure that API interactions take place over an encrypted channel. API data evaluation and sanitization should be carried out before using the data further. Precautionary actions should be taken to avoid unnecessary redirections by using Allow lists. How F5 XC can help? F5 Distributed Cloud (F5 XC) has a wide range of solutions for deploying, managing and securing application deployments in different environments. XC WAAP is a F5 SaaS offering. The 4 key components of WAAP are Web Application Firewall, API Security, Bot Defense, DDoS Mitigation. All these solutions are powered on top of the XC platform. In addition to WAAP, F5 XC has other solutions to offer such as Fraud and Abuse, AIP, CDN, MCN, DNS and so on. API security in XC WAAP simplifies operations with automated discovery of API transactions using AI/ML Engine along with insights of performance. It also provides API protection features like Rate Limiting, PII safeguard along with comprehensive security monitoring GUI dashboard. API security provides feasibility to import the inventory file in the form of swagger which helps to know exactly what endpoints, methods and payloads are valid, and this tightens security against abuse. F5 XC management console helps the customers to leverage the benefit of monitoring, managing, and maintaining their application’s traffic from a single place irrespective of its platform on which it is hosted, it could be multi-cloud, on prem or edge. Note: This is an initial article covering the overview of proposed most critical API vulnerabilities from OWASP API Security community for 2023. More articles covering detailed insight of each vulnerability and their mitigation steps using F5 XC platform will follow this article in coming days. Meanwhile, you can refer to overview article for OWASP API Security Top 10 2019 which contains link to detailed articles covering API vulnerabilities of 2019 and how F5 XC can help to mitigate them. Related OWASP API Security article series: Broken Authentication Excessive Data Exposure Mass Assignment Lack of Resources & Rate limiting Security Misconfiguration Improper Assets Management Unsafe consumption of APIs Server-Side Request Forgery Unrestricted Access to Sensitive Business Flows OWASP API Security Top 10 - 2019Introduction 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 ServicesUse F5 Distributed Cloud to Connect Apps Running in Multiple Clusters and Sites
Introduction Modern apps are comprised of many smaller components and can take advantage of today’s agile computing landscape. One of the challenges IT Admins and Security Operations face is securely controlling access to all the compofnents of distributed apps while business development grows or changes hands with mergers and acquisitions, or as contracts change. F5 Distributed Cloud (F5 XC) makes it very easy to provide uniform access to distributed apps regardless of where the components live. Solution Overview Arcadia Finance is a distributed app with modules that run in multiple Kubernetes clusters and in multiple locations. To expedite development in a key part of the Arcadia Finance distributed app, the business has decided to outsource work on the Refer A Friend module. IT Ops must now relocate the Refer A Friend module to a separate location exclusive to the new contractor where its team of developers have access to work on it. Because the app is modular, IT has shared a copy of the Refer A Friend container to the developer, and now that it is up and running in the new site, traffic to the module needs to transition away from the one that had been developed in house to the one now managed by the contractor. Logical Topology Distributed App Overview The Refer A Friend endpoint is called by the Arcadia Finance frontend pod in a Kubernetes (K8s) cluster when a user of the service wants to invite a friend to join. The pod does this by making an HTTP request to the location “refer-a-friend.demo.internal/app3/”. The endpoint “refer-a-friend.demo.internal” is registered as a discoverable service in the K8s cluster using an F5 XC App Connect HTTP Load Balancer with its VIP configured to be advertised internally to specific sites, including the K8s cluster. F5 XC uses the cluster’s K8s management API to register service names and make them available anywhere within a global network belonging to a customer's tenant. Three sites are used by the company that owns Arcadia Finance to deliver the distributed app. The core of the app lives in a K8s cluster in Azure, the administration and monitoring of the app is in the customer’s legacy site in AWS. To maintain security, the new contractor only has access to GCP where they’ll continue developing the Refer A Friend module. An F5 XC global virtual network connects all three sites, and all three sites are in a site mesh group to streamline communication between the different app modules. Steps to deploy To reach the app externally, an App Connect HTTP Load Balancer policy is configured using an origin pool that connects to the K8s “frontend” service, and the origin pool uses a Kubernetes Site in F5 XC to access the frontend service. A second HTTP Load Balancer policy is configured with its origin pool, a static IP that lives in Azure and is accessed via a registered Azure VNET Site. When the Refer A Friend module is needed, a pod in the K8s cluster connects to the Refer A Friend internal VIP advertised by the HTTP Load Balancer policy. This connection is then tunneled by F5 XC to an endpoint where the module runs. With development to the Refer A Friend module turned over to the contractor, we only need to change the HTTP Load Balancer policy to use an origin pool located in the contractor’s Cloud GCP VPC Site. The origin policy for the GCP located module is nearly identical to the one used in Azure. Now when a user in the Arcadia App goes to refer a friend, the callout the app makes is now routed to the new location where it is managed and run by the new contractor. Demo Watch the following video for information about this solution and a walkthrough using the steps above in the F5 Distributed Cloud Console. Conclusion Using Distributed Cloud with modern day distributed apps, it’s almost too easy to route requests intended for a specific module to a new location regardless of the provider and provider specific requirements or the IP space the new module runs in. This is the true power of using Distributed Cloud to glue together modern day distributed apps.Mitigating OWASP API Security Risk: Security Misconfiguration using F5 XC Platform
Overview This article is a continuation of the series of articles on OWASP API Security vulnerabilities and demonstrates a scenario for mitigating API Security Misconfiguration using F5 Distributed Cloud(XC) Platform. See F5 Distributed Cloud API Security dynamically discover and automatically protect API endpoints. Introduction to OWASP API Security Misconfiguration APIs are the backbone of the modern application development model and because of their heavy usage they often become victim of attacks. Sometimes these vulnerabilities arise if security best practices are missed and are not followed properly in application development life cycle. Below are a few scenarios which fall under API Security Misconfiguration category: Latest security patches are not applied. Unnecessary HTTP verbs are enabled exposing APIs to get accessed by them. Improper implementation of CORS policy. Missing repeatable security hardening process. Exposing detailed stack trace error messages or sensitive information. Problem Statement Improperly configured CORS policies can expose web applications to vulnerabilities, allowing malicious actors to perform unauthorized actions or access sensitive data. This poses significant risks to user privacy, application integrity, and organizational security. In the demonstration below we will cover a scenario where the application is vulnerable to CORS and will see how F5 Distributed Cloud WAAP can help in identifying and mitigating such threats. What is Cross-Origin Resource Sharing (CORS) ? CORS is a security feature implemented by browsers to allow or block web applications from making requests to domains other than their own. This mechanism helps prevent certain types of attacks, by ensuring that only authorized domains can access certain resources. CORS occurs only when the target server(cross-origin) is accessed from other domains and sub-domains. CORS works by specific HTTP/S headers that allow a server to explicitly specify which origins are allowed to access its resources and which methods and headers can be used. Preflight Request: When making cross-origin requests that are complex (i.e., requests that use non-simple methods, custom headers, or credentials), the browser sends an OPTIONS request before the actual request which is called the preflight request. The preflight request is used to check if the server will allow the actual request. Specifically, a preflight request occurs when a web page makes a cross-origin HTTP request that does not meet the simple request criteria defined by the CORS specification. Consider the scenario below, where authentication request in the origin server is handled by some third-party cross-origin server. If the cross-origin server is not configured to block untrusted origins based on domain, methods and headers, attacker can take advantage of this vulnerability by performing harmful action using methods and headers in requests. 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 2019Mitigating OWASP Web Application Security Top 10 – 2021 risks using F5 Distributed Cloud Platform
Overview: In the early 90’s, applications were in dormant phase and JavaScript & XML were dominating this technology. But in 1999, the first web application was introduced after the release of the Java language in 1995. Later with the adoption of new languages like Ajax, HTML, Node, Angular, SQL, Go, Python, etc. and availability of web application frameworks have boosted application development, deployment, and release to production. With the evolving software technologies, modern web applications are becoming more and more innovative, providing users with a grand new experience and ridiculously ease of interface. With these leading-edge technologies, novel exploit surfaces are also exposed which made them a primary target for intruders/hackers. Application safeguarding against all these common exploits is a necessary step in protecting backend application data. Open Worldwide Application Security Project (OWASP) is one of those security practices which protects application with above issues. This article is the first part of the series and covers OWASP evolution, its importance and overview of top 10 categories. Before diving into OWASP Web Application Security Top 10, let’s time travel to era of 1990’s and try to identify challenges the application customers, developers and users were facing. Below are some of them: Rapid and diversified cyber-attacks has become a major concern and monitoring/categorizing them was difficult Product owners are concerned about application security & availability and are in desperate need of a checklist/report to understand their application security posture Developers are looking for recommendations to securely develop code before running into security flaws in production No consolidated repo to manage, document and provide research insights for every security vulnerability After running into the above concerns, people across the globe have come together in 2001 and formed an international open-source community OWASP. It’s a non-profit foundation which has people from different backgrounds like developers, evangelist, security experts, etc. The main agenda for this community is to solve application related issues by providing: Regularly updating “OWASP TOP 10” report which provides insights of latest top 10 security issues in web applications Report also provides security recommendations to protect them from these issues Consolidated monitoring and tracking of application vulnerabilities Conducting events, trainings and conferences around the world to discuss, solve and provide preventive recommendations for latest security issues OWASP also provides security tools, research papers, libraries, cheat sheets, books, presentations and videos covering application security testing, secure development, and secure code review OWASP WEB SECURITY TOP 10 2021: With the rapid increase of cyber-attacks and because of dynamic report updates, OWASP gained immense popularity and is considered as one of the top security aspects which application companies are following to protect their modern applications against known security issues. Periodically they release their Top 10 vulnerabilities report and below are the latest Top 10 - 2021 categories with their summary: A01:2021-Broken Access Control Access controls enforce policy such that users cannot act outside of their intended permissions. Also called authorization, it allows or denies access to your application's features and resources. Misuse of access control enables unauthorized access to sensitive information, privilege escalation and illegal file executions. Check this article on protection against broken access vulnerabilities A02:2021-Cryptographic Failures In 2017 OWASP top 10 report, this attack was known as Sensitive Data Exposure, which focuses on failures related to cryptography leading to exposure of sensitive data. Check this article on cryptographic failures A03:2021-Injection An application is vulnerable to injection if user data and schema is not validated by the application. Some of the common injections are XSS, SQL, NoSQL, OS command, Object Relational Mapping (ORM), etc., causing data breaches and loss of revenue. Check this article on safeguarding against injection exploits A04:2021-Insecure Design During the development cycle, some phases might be reduced in scope which leads to some of the vulnerabilities. Insecure Design represents the weaknesses i.e., lack of security controls which are not tracked in other categories throughout the development cycle. Check this article on design flaws and mitigation A05:2021-Security Misconfiguration This occurs when security best practices are overlooked allowing attackers to get into the system utilizing the loopholes. XML External Entities (XXE), which was previously a Top 10 category, is now a part of security misconfiguration. Check this article on protection against misconfiguration vulnerabilities A06:2021-Vulnerable and Outdated Components Applications used in enterprises are prone to threats such as code injection, buffer overflow, command injection and cross-site scripting from unsupported, out of date open-source components and known exploited vulnerabilities. Utilizing components with security issues makes the application itself vulnerable. Intruders will take use of this defects and exploit the deprecated packages thereby gaining access to backend applications. Check this article on finding outdated components A07:2021-Identification and Authentication Failures Confirmation of the user's identity, authentication, authorization and session management is critical to protect applications against authentication-related attacks. Apps without valid authorization, use of default credentials and unable to detect bot traffic are some of the scenarios in this category. Check this article on identifying and protection against bots A08:2021-Software and Data Integrity Failures Software and data integrity failures occurs when updates are pushed to the deployment pipeline without verifying its integrity. Insecure Deserialization, which was a separate category in OWASP 2017, has now become a part of this larger category set. Check this article on software failures protection A09:2021-Security Logging and Monitoring Failures As a best recommendation, we shall always log all incoming request details and monitor application for fraudulent transactions, invalid logins, etc. to identify if there are any attacks or breaches. Applications without logging capabilities provide opportunities to the attackers to exploit the application and may lead to many security concerns. Without logging and monitoring we won’t be able to validate the application traffic and can’t identify the source of the breach. Check this article for identifying logging issues A10:2021-Server-Side Request Forgery Server-Side Request Forgery (SSRF) attack is a technique which allows intruders to manipulate the server-side application vulnerability and make a malicious request to the internal-only resources. Attacker exploits this flaw by modifying/crafting a URL which forces the server to retrieve and disclose sensitive information. Check this article which focusses on SSRF mitigation NOTE: This is an overview article of this OWASP series, check the below links to prevent these vulnerabilities using F5 Distributed Cloud Platform. OWASP Web Application Security Series: Broken access mitigation Cryptographic failures Injection mitigation Insecure design mitigation Security misconfiguration prevention Vulnerable and outdated components Identification failures prevention Software failures mitigation Security logging issues prevention SSRF MitigationMitigating OWASP Web Application Risk: Broken Access attacks using F5 Distributed Cloud Platform
This article is in continuation of the owasp series and will cover broken access control. Check here for overview article. Introduction to Broken Access Control attack: Access controls enforces policy such that users cannot act outside of their intended permissions. Also called authorization, allows or denies access to your application's features and resources. Misuse of access control enables: Unauthorized access to sensitive information. Privilege escalation. Illegal file executions. There are many ways to infiltrate application servers using broken access controls and we are going to focus on the 2 scenarios below and how to mitigate them. Scenario 1: Broken access + SQL injection attack Instead of logging with valid credentials, attacker uses SQL injection attacks to login as another standard or higher privileged user, like admin. We can also say this is broken authentication, because an attacker authenticated to a system using injection attack without providing valid credentials. For this demo I am using OWASP Juice shop (reference links at bottom for more info). Step1: Please follow steps suggested in Article1 to configure HTTP load balancer and WAF in cloud console. Make sure WAF is configured in Monitoring mode to generate the attack. Step2: Open a browser and navigate to the login page of the application load balancer. In the Email field provide “' OR true --” and any password as below: Step3: Validate you can login to application as administrator as below: Scenario2: File upload vulnerability Any file which has the capability to harm the server is a malicious file. For example, a php file which has some dangerous php functions like exec () can be considered as a malicious file as these functions can execute OS command and can remotely provide us the control of the application server. Suppose there is a file upload functionality in the web application and only jpeg extension file is allowed to be uploaded. Failing to properly enforce access restrictions on file properties can lead to broken access control attacks providing attackers a way to upload potentially dangerous files with different extensions. For this demo I am using DVWA as the vulnerable testing application (reference links at bottom for more info). Step by step process: Step1: Open a notepad editor and paste below contents and save to desktop as malicious.php Step2: Open a browser and navigate to the application load balancer URL. Login to DVWA application using admin/password as the credentials. Click on “File Upload” option in left side of the menu section. Step3: This page is used to upload images with extensions .jpeg, .png, .gif etc. But this demo application doesn’t have file restrictions enabled making attackers to upload any file extensions. Click on “Choose File” button and upload above created .php file. Step4: Note the location displayed in the message, open the URL in the browser and validate we can see all the users available as below. NOTE: Since this is just a demo environment, I'm using same F5 Distributed Cloud load balancer for both the demo applications by changing the IP and ports in F5 Distributed Cloud Origin pool as per my needs. That's why you can see both apps are accessible using juiceshop domain. Solution: To mitigate these attacks, navigate to Firewall section and in “App Firewall” configuration make sure “Enforcement Mode” is set to “Blocking” as below: Next in browser try to generate above scenarios and validate your request is blocked as below. Login Mitigation: Illegal File Upload mitigation: Illegal File Execution mitigations: In Distributed Cloud Console expand the security event and check the WAF section to understand the reason why request was blocked. Conclusion: As shown above, OWASP Top 10: Broken access control attacks can be mitigated by configuring WAF firewall in “Blocking” mode. For further information click the links below: OWASP - Broken access control File Upload Vulnerability OWASP Juice Shop DVWAMulti-port support for HTTP/TCP load balancers in F5 Distributed Cloud (XC)
Overview: In the ever-evolving landscape of the digital world driven by innovation, catering to the new requirements is vital for modern application scalability, adaptability, and longevity. Multi-port support refers to the capability of a system to handle and manage multiple application ports simultaneously. This flexibility is particularly important in scenarios where a single device needs to serve diverse services. Multi-port support is essential for various reasons, including some of the below: Parallel Processing: It allows the system to process multiple app streams concurrently, enhancing efficiency and reducing latency. Diverse Services: Different applications or services often require dedicated ports to function. Multi-port support enables a system to accommodate a variety of services simultaneously. Load Balancing: Distributing application traffic across multiple ports helps balance the load, preventing bottlenecks and optimizing resource utilization. Security: Sometimes SecOps want to have testing ports opened, which allow access to applications for testing, scanning, monitoring, and addressing potential security vulnerabilities. Flexibility: Systems with multi-port support are adaptable to modern micro-service-based architectures, supporting a diverse range of applications and services. IP limitations: Since IP’s are limited, customers don’t want to use a different IP for each user, so instead they want to reserve a single IP and want to distribute load on different ports. Note: For today’s demonstration, we have deployed multiple demo applications like JuiceShop, DVWA, NGINX, F5 Air as micro-services on multiple systems/ports to showcase the capabilities of multi-port support and their deployment steps are out of scope in this article. Let’s unravel three below real-world use cases of multi-port support and how it can be implemented in F5 Distributed Cloud (F5 XC) in easy-to-follow steps. Use case I – Multiple Ports In this use case, let’s assume the customer already has onboarded his backend application as an origin pool in XC. Next, the customer wants to access the same application using multiple ports, either for genuine access or for testing. For achieving this use case, follow below steps: Login to F5 XC console and navigate to “Distributed Apps” --> “Manage Load balancer” section For this use case, create a HTTP load balancer with your backend application, needed ports in csv format, type as HTTP, name, domain name as shown below. NOTE: Provide only unused ports or you will run into port conflict errors. Also configure DNS records as per your setup. Once load balancer is created successfully, validate your application is accessible on the configured port and LB domain name Use case II – Port Range In this scenario, customers have the requirement to access an application in a range of ports either for parallel processing or load balancing. For configuration, follow below steps: Login to F5 XC console and navigate to “Distributed Apps” section For this use case, create a HTTPS load balancer with your backend application, needed port range and domain name as shown below. NOTE: Provide only unused port range to avoid port conflict error. Validate your application is accessible on configured ports just like below Use case III – Origin Pool Dynamic port In this requirement, the backend application port should be dynamic and is dependent on the load balancer access port number. Let’s say a customer has multiple services running on multiple ports and wants users to access these services using a single TCP load balancer. To meet this solution, follow steps below: Login to F5 XC console and navigate to “Distributed Apps” section Next, move to “Origin Pool” section and onboard your basic backend application details and select the "origin server port" option as the "loadbalancer port" (as shown below). We can also configure health checks to LB ports instead of endpoints for better visibility. We are halfway there!!. Move to “TCP Load balancer” section and create a TCP load balancer with required port ranges and your application origin pool. Your configuration will look something like below Finally for the fun part: Once load balancer comes to a READY state, open a browser and make sure different services are accessible on configured domain name and ports shown below NOTE: For above solution to work, multiple services should be running on the configured ports of backend system and this port range should be unused by other services on the XC platform We have just scratched the surface of the the wide range of use cases of multi-port and there is a lot of demand in the market for many scenarios combining different functionalities of HTTP/HTTPS/TCP, single/multi services on same system or multiple backend systems and can also be routed to appropriate backends using port range filters in routes. As per customer requirements, appropriate configurations can be done on F5 XC for seamless integration and to leverage the pervasive WAAP security ecosystem. Conclusion: Winding up, this article pondered the market demand for the support of multi-port range in HTTP/TCP load balancers and then we took you on a roller coaster ride of different use cases. Finally, we also demonstrated how F5 XC can foster in shaping and optimizing your application versatile multi-port requirements. Ever wondered what is F5 XC and how it acts as a “Guardian of Applications”, check below links: F5 Distributed Cloud Services F5 Distributed Cloud WAAP
