Introduction 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 securitypractices. 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 performedbefore 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 appliedto detect &mitigate credential stuffing, dictionary and brute force type of attacks. API3:2023 Broken Object Property Level Authorization Broken Object Property Level Authorization is one of the new risk categories of OWASP API Security Top 10 2023 RC. 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 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 propertyshould be scrutinized before exposureby 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 asthat of Lack of Resources & Rate Limiting. To prevent this vulnerability, rate-limiting, maximum size forinput 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:2023Unrestricted 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 ofAPI10: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 RC 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 dataobeys the expected format. Allow lists should be maintained so thatonly trusted requests/calls will be processed, andHTTP 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 arethe keyto 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 Injectionvulnerability. 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 initialarticle 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 - 2019OWASP Tactical Access Defense Series: Broken Object Property Level Authorization and BIG-IP APM
AUTHOR NOTE: Unauthorized access to private/sensitive object properties may result in data disclosure, data loss, or data corruption. Under certain circumstances, unauthorized access to object properties can lead to privilege escalation or partial/full account takeover. In this article we are going through API3 item from OWASP top 10 API Security risks exploring BIG-IP Access Policy Manager (APM) role in our arsenal. Identifying Vulnerable APIs In order to identify the API endpoint is vulnerable to Broken Object Property Level Authorization, Sensitive properties exposure of certain object for non-intended user (Excessive Data Exposure). import requests # Assuming the API endpoint for retrieving user data is /api/users api_endpoint = "https://example.com/api/users" # Sending a GET request to the API endpoint response = requests.get(api_endpoint) # Checking if the request was successful (status code 200) if response.status_code == 200: # Printing the response content (which could contain excessive data) print(response.json()) else: print("Failed to retrieve data from the API") API allow to change, add or delete sensitive object property for non-intended user (Mass assignment). import requests # Assuming the API endpoint for updating user information is /api/users api_endpoint = "https://example.com/api/users" # Malicious payload containing additional fields malicious_payload = { "username": "malicious_user", "password": "password123", "isAdmin": True # Malicious user attempts to elevate privileges } # Sending a POST request with the malicious payload response = requests.post(api_endpoint, json=malicious_payload) # Checking if the request was successful (status code 200) if response.status_code == 200: print("User information updated successfully") else: print("Failed to update user information") Object Property Level Authorization involves controlling access to specific properties or attributes of an object within a system. Instead of granting blanket access to an entire object, this approach enables fine-grained control, allowing administrators to restrict or permit access to individual properties based on user roles or permissions. While implementing protection against such security risk involves different aspects, one is making sure the user is authorized to access object property, and here BIG-IP APM plays crucial role. Mitigating Risks with BIG-IP APM BIG-IP APM per-request granularity. With per-request granularity, organizations can dynamically enforce access policies based on various factors such as user identity, device characteristics, and contextual information. This enables organizations to implement fine-grained access controls at the API level, mitigating the risks associated with Broken Object Property Level Authorization. Key Features: Dynamic Access Control Policies: BIG-IP APM empowers organizations to define dynamic access control policies that adapt to changing conditions in real-time. By evaluating each API request against these policies, BIG-IP APM ensures that only authorized users can access specific resources and perform permitted actions. Granular Authorization Rules: BIG-IP APM enables organizations to define granular authorization rules that govern access to individual objects or resources within the API ecosystem. By enforcing strict authorization checks at the object level, F5 APM prevents unauthorized users from tampering with sensitive data or performing unauthorized actions. Conclusion In conclusion, BIG-IP APM per-request granularity is a powerful tool for defending against Broken Object-Level Authorization vulnerabilities in APIs. By enforcing fine-grained access controls at the API level, organizations can mitigate the risks associated with unauthorized access to sensitive data. Additionally, proactive security assessments and vulnerability scans are essential for identifying and addressing vulnerabilities in APIs, thereby strengthening overall security posture in the digital ecosystem. Related Content F5 BIG-IP Access Policy Manager | F5 Introduction to OWASP API Security Top 10 2023 OWASP Top 10 API Security Risks – 2023 - OWASP API Security Top 10 API Protection Concepts OWASP Tactical Access Defense Series: How BIG-IP APM Strengthens Defenses Against OWASP Top 10 OWASP Tactical Access Defense Series: Broken Object Level Authorization and BIG-IP APM F5 Hybrid Security Architectures (Part 5 - F5 XC, BIG-IP APM, CIS, and NGINX Ingress Controller) OWASP Tactical Access Defense Series: Broken Authentication and BIG-IP APMMitigation of OWASP API Security Risk: Unrestricted Access to Sensitive Business Flows using F5 XC
We have already covered different OWASP API risks in our previous articles (check reference section for more details). OWASP continuously analysed API threats in the last few years and has identified new types of risks which are not part of API Security Top 10 - 2019 edition. So, they added these new ones in the 2nd edition of OWASP API Security Top 10 2023 list and this article will cover the nuances of the newly added risk: Unrestricted Access to Sensitive Business Flows. Introduction: API owners should be very cautious of all the API endpoint’s exposed to users and they should identify each endpoint’s business justification. When developing an API Endpoint, we shall understand API use case and its intended scope of user action. Some business flows need to be monitored, restricted or blocked depending on the sensitivity of endpoint data. If any sensitive business flow is not protected, attackers can exploit them and cause some serious damage to the business. Using wide variety of automated tools available in market, hackers can automate the manual processthereby adversely impacting the genuine business workflows. That’s all the theory I have !!. Let’s plunge into a demo application use case and discover how F5 Distributed Cloud Platform (XC) can detect and guard our API application endpoints against this vulnerability. Use case: As part of testing, I was exploring the options available in one of the demo application “F5AIR” which is used for booking some dummy flight tickets and as a promotion this application is also offering 200$ as account balance after every user signup. In the 3rd tab we observed that this balance can be used to create gift cards which can be redeemed by users. After doing thorough research we have identified there are no restrictions on this workflow and it can be exploited using automated tools. Automated tools can be used to create multiple users, generate gift cards from each user and then redeem them into a single valid account to further book flight tickets without paying anything. Because of this risk, businesses can incur losses and so this is marked as a sensitive business flow. Artificial Intelligence is a truly disruptive technology spreading like wildfire and so for the purpose of today’s demo, I am using AXIOM.AI browser extension to automate the above manual workflow steps. It just took me around 30 minutes to understand how it works and was able to automate the above exploited manual steps. After 10 user creations and redeeming their gift cards valid main user will have around 2000$ which can be used to book flight tickets. Note: To showcase how AI tools can be leveraged to exploit modern applications we are using axiom ai tool and intended only for educational purposes. Mitigation Steps: A straightforward one-point solution may not be appropriate for different types of these vulnerabilities. Secops team should dig deeper into their incoming application traffic, differentiate genuine & malicious security data and then identify the API endpoints which are sensitive to their business flows. Once they have analyzed the traffic then they can apply below solutions as per their requirements Configure API Discovery to detect different API vulnerabilities like sensitive Data, API Attributes like Login page, Zombie API, security Posture, etc. You can find more details in this article Configure rate limiting on the sensitive business end points to keep a limit on number of requests - check here for more details on rate limiting Configure API Protection rules for these business API’s to restrict access to applications – check here for more details on API rules Configure Bot Defense to prevent bot attacks – check here for more details on bot protection As an example, let’s consider the above demonstrated AI tool example, to block any botsfrom accessing demo application we can apply bot defense configurations in root folder location “/” as shown below after which bot AI exploit requests can be mitigated. Note: Above config is for this article’s use case, but users must understand the API endpoint’s which should be protected and apply configs appropriately. We can also try other automation tools like postman which may also be blocked as below In F5 XC console if we navigate to this load balancer security events and bot defense dashboards, we can see these requests are blocked. Conclusion: In this article we explored some insights on this newly added OWASP API Security Top 10 risk, then we shed some light on how AI tools have opened floodgates to a new approach of application threats. Finally, we also revealed the final puzzle of how F5 XC Bot defense can become our elixir in identifying and protecting against this OWASP API risk along with novel AI threats. For more information or to get started check links below: OWASP API Security Top 10 2023 OWASP API Security Top 10 - 2019 F5 Distributed Cloud WAAP
OWASP Tactical Access Defense Series: Broken Authentication and BIG-IP APM
The threat of broken authentication poses a significant risk to organizations, potentially leading to unauthorized access and data breaches. In the face of this formidable challenge, F5's Access Policy Manager (APM) emerges as a robust and indispensable solution. By seamlessly integrating advanced authentication mechanisms and comprehensive access controls, F5 BIG-IP APM stands as a stalwart guardian against the vulnerabilities associated with broken authentication. This article explores the pivotal role played by BIG-IP APM in fortifying authentication protocols, mitigating risks, and ensuring a resilient defense against unauthorized access, ultimately safeguarding the integrity and security of sensitive data in today's dynamic digital environment. Broken Authentication Broken Authentication Examples BIG-IP APM and Broken Authentication Related Content Broken Authentication Authentication mechanism is an exposed target due to the nature of this function, as authentication is the first point of entry to any platform. The difficulty to exploit authentication weaknesses differs based on how the authentication platform is secured. In the current digital era the security perimeters are very fluid, and so are the trust boundries for our authentication platforms those require more cautions from the developers and security architects regarding authentication flows. Not only we need to protect authentication endpoints and flows, but also some overlooked items like forget and reset password endpoints. How can we consider endpoint to be vulnerable? Credential stuffing. Brute force attacks targetting users' accounts. Weak Passwords. Sensitive details in the URL (passwords, Tokens). Allow users sensitive actions without confirmation. No validation for the tokens authenticity. Accept unsigned or weak jwt tokens. No validation for jwt expiration. Use of plain-text, non-encrypted or non-hashed passwords. Use of weak encryption algorithms. Endpoint can access each other without proper authentication. Use weak or predictable tokens for intra-endpoint authentication. Broken Authentication Examples Making use of GraphQL query patching to bypass API ratelimiting and brute force user's login. POST /graphql [ {"query":"mutation{login(username:\"victim\",password:\"password\"){token}}"}, {"query":"mutation{login(username:\"victim\",password:\"123456\"){token}}"}, {"query":"mutation{login(username:\"victim\",password:\"qwerty\"){token}}"}, ... {"query":"mutation{login(username:\"victim\",password:\"123\"){token}}"}, ] Update / modify user's sensitive information without API authorization token. PUT /account Authorization: Bearer <token> { "newpassword": "<new_password>" } BIG-IP APM and Broken Authentication We start with creating our Per-Request policy, this policy works in a different way than the per-session policy, as the flow will be evaluted on a per-request basis, making sure to consider variations throught the session life-time. Below are some of the key benefits: Wide range of Authentication, SSO, and MFA mechanisms to properly identify the initiating machine or user. Ability to integrate with 3rd parties to provide additional enforcement decisions based on the organization's policy. Ability to apply endpoint checks on the client side before session initiation. This goes to BIG-IP in general, the ability to apply custom traffic control on both of the traffic sides, Client and Server. The ability to create whitelist / blacklist for API Access tokens, JSON Web Tokens ID (JTI) or a different element based on the used authentication method, below example steps for JWT: Extract JTI value from Access token. Add JTI value to whether Allow/Block lists. Related Content F5 BIG-IP Access Policy Manager | F5 Introduction to OWASP API Security Top 10 2023 OWASP Top 10 API Security Risks – 2023 - OWASP API Security Top 10 API Protection Concepts OWASP Tactical Access Defense Series: How BIG-IP APM Strengthens Defenses Against OWASP Top 10 OWASP Tactical Access Defense Series: Broken Object Level Authorization and BIG-IP APM F5 Hybrid Security Architectures (Part 5 - F5 XC, BIG-IP APM, CIS, and NGINX Ingress Controller)Mitigating 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: Security Logging & Monitoring Failures using F5 XC Platform
Overview: The overview articlecovered a brief introduction about OWASP Top 10 Vulnerabilities related to Web Application. This article is continuation of the series and shows importance of Security Logging and Monitoring and how F5 Distributed Cloud (F5 XC) can contribute to mitigate the threats. It occupies position #10 in 2017 as Insufficient Logging and Monitoring and it has moved to position #9 in 2021. Introduction to Security Logging and Monitoring Failures: Security logging and monitoring failures is integrated as one process to log request such as logins, transactions during runtime and other operations which could cause harm to the application via attacks, breach attempts and suspicious behavior from user operations etc. and these activities must be monitored, and the decision must be taken at the earliest. An attack or breach attempt maynot be identifiable due to lack of logging and monitoring failures. Ignoring malicious activities could provide opportunities to the attackers to exploit the application and may lead to disallow valid users from accessing the application, loss of data, revenue, and reputation as well. Reports find that the mean time to identify the attack is around 200 days due to applications susceptible to modern day attacks and many other reasons as well. Generic use case demonstration: From the above logs it is tedious to categorise requests based on type and their severity and hence it is difficult to identify the attacks or anomalies from it. There is no point in logging the requests and not presenting them in easily understandable GUI format which helps security teams to detect and respond to the security events, if any. Professional and comprehensive Solution: A Web application should always have capability of logging events such as, User logins Warning and error messages Appropriate alerting threshold Attack Detection F5 XC stores log requests as mentioned above along with its detailed information. F5 XC categorizes the logs based on different dimensions of its characteristics and displays them in GUI template according to Customer needs which helps them to understand better about their behaviour. This elaborativeway of logging and displaying logs makes it easier for forensic analysis and investigation. Security Monitoring Dashboard gives an integrated view of overall primary essence of attack details for a given time stamp. Below is the information that can be extracted from the above dashboard picture. Displays security events by their type and top attacked sites from respective source IP’s along with geographical location as well. Top attack types by their signatures ID give detailed view on attacker’s approach to violate the application behaviour. Traffic is processed by aggregatingfor better understanding on categories such as Malicious Users, Security Events, DDoS tabs etc, as mentioned above. This provides critical intelligence of application security at your fingertips. Filtering enables the security team to easy debug and identify the issues. It helps in narrowing down to identify the abnormal behaviour based on multiple parameters like country, URL, region etc. F5 XC enhances the alerts with additional information for the customers to make decisions faster. Along with above dashboard, performance monitoring dashboard gives information on performance and latency of each request which makes F5 XC logging more comprehensive. From the above dashboard we can observe request rate, throughput rate, top URL accessed which tells us about the performance of the application. Following tabs such as Metrics, Requests etc, give a detailed view on Traffic rate and Individual traffic requests parameters reaching the application. Conclusion: F5 XC comes with modern UI templatesand graphical representation especially when it comes to Logging and Monitoring Failures for better analysis. With the modern-day attacks growing drastically these eases application developers’ worry about prioritizing the attacks and malicious activities. This level of intelligence in Logging and Monitoring helps to bring down the mean time to identify the attack to almost immediate. This makes F5 XC more professional and comprehensive. Related Links: OWASP Top 10: 2021 Vulnerability List Overview Owasp.org/Security_Logging_and_Monitoring_FailuresMitigating OWASP Web Application Risk: SSRF Attack using F5 XC Platform
Introduction to SSRF attack: In recent OWASP Web Application Top 10 report, SSRF is observed as one of the widely happening web application attack. Please refer to OWASP WebApp Top10 article for more details on Top 10 vulnerabilities. This article demonstrates the SSRF attack and its mitigation technique using F5 Distributed Cloud platform. Server-Side Request Forgery (SSRF) attack is a technique which allows an attacker to manipulate the server-side application vulnerability and make a malicious request to the internal-only resources. These internal resources are not intended to be exposed to the outside world, instead they are used by the web application to fetch configurations such as Metadata, connect to internal databases and read the data, communicate with the peer web applications. Attacker exploits the web application by modifying/crafting a URL which forces the server to retrieve and disclose sensitive information from the internal servers which are not accessible from outside world. Demonstration: In this demonstration, we will see how to generate a simple SSRF attack and mitigate it using F5 Distributed Cloud (F5 XC) platform. We are using: AWS instance with Docker DVWA vulnerable application installed as container to act as a target for the SSRF attack F5 Distributed Cloud (F5 XC) Platform for mitigation Brief on SSRF attack scenario in AWS: The AWS instance uses an internal web service to obtain its metadata i.e., instance specific information and this metadata service can be accessed only from the AWS instance. When EC2 instance requires any kind of metadata, it initiates a request to this service and the information gets served according to the request made. AWS uses 169.254.169.254 address to fetch the Instance metadata. As shown in the above architecture, a vulnerable application is deployed in an AWS instance. Attackers can access the application and try to exploit this vulnerable application. This can be done by modifying orproviding a URL that will initiate a request from the AWS instance to the internal web service and retrieve the sensitive metadata. Step by Step process: Launch an EC2 instance. Deploy DVWA application in the instance and make sure the application is up and running. Configure HTTP load balancer in F5 XC without enabling WAF policy. Please follow below provided steps on how to configure F5 XC HTTP load balance. Access the backend vulnerable application using configured load balancer domain. Wait for the application to load and login to the application. Navigate to “File Inclusion” page in the application. In the URL, modify the value of query parameter ‘page’ to http://169.254.169.254/latest/meta-data/ Observe that application page displays sensitive metadata of the EC2 instance. The retrieved metadata will be displayed on the vulnerable application as below. Configuration of HTTP Load balancer for mitigation of attack: Step 1: Creation of Origin Pool From your desired namespace, navigate to Manage > Load Balancers > Origin pools. Click on "Add Origin Pool" and provide a name for Origin pool. Configure Origin server details with valid Port details. Step 2: Configuration of Load Balancer with WAF enabled Navigate to Manage -> Load Balancers -> HTTP Load Balancers Click on "Add HTTP load balancer" and provide a name for the Load Balancer Provide valid domain name and choose appropriate load balancer type under Basic Configuration Associate the above created Origin Pool in the load balancer. Enable “Web Application Firewall”and create a WAF configuration with Blocking mode Click on Continue and observe that above created WAF configuration is being used. Click on “Save and Exit”. Step 3: Access the vulnerable application and repeat the attack scenario. In browser, access the backend application using configured load balancer domain. Wait for the application to load and login to the application. Navigate to “File Inclusion” page in the application. In the URL, modify the value of query parameter ‘page’ to http://169.254.169.254/latest/meta-data/ Observe that page cannot read metadata of the server and request gets blocked due to WAF policy. Step 4: Validate logs and blocked request details Navigate to Virtual Hosts -> HTTP Load Balancers -> choose appropriate load balancer -> Security Monitoring -> Security events Observe that malicious request gets blocked due to applied WAF policy Expand the request and observe details about blocked request Conclusion: As you can see from the above demonstration, SSRF attacks can be mitigated by configuring a WAF policy in F5 Load balancer which automatically detects attack signature and block them. Reference Links: F5 Distributed Cloud Services F5 Distributed Cloud WAFMitigating OWASP Web Application Risk: Cryptographic Failures using F5 Distributed Cloud Platform
Introduction to OWASP: Introduction article covered details of OWASP and 3 more articles in sequence covered Injection, broken access and authentication failures (check reference links for more details). This 4th article is in continuation of the series and will cover Cryptographic Failures. Introduction to Cryptographic Failures: In 2017 this attack is known as Sensitive Data Exposure, which focuses on failures related to cryptography which often lead to exposure of sensitive data. For this demo we are using OWASP Juice Shop as a vulnerable application which is exposing some files in ftp server location as below. This website has file type limitations kept in place to restrict users from downloading only .md/,pdf files. For example, let’s say we have a file with the name eastere.gg file which has some sensitive details and when we try to download directly, we get 403 error as below: Step by step testing process: Step1: Please follow the suggested steps here to configure HTTP load balancer and WAF in cloud console. Make sure WAF is configured in Monitoring mode only to analyze the attack. Step2: Hackers can find a way to bypass this file cryptographic restriction. For example, as shown below we can intercept the outgoing request using burp suite and just by adding null byte to the filename we are able to download the file (%2500.md is a null byte which is equal to empty space in cryptography). Prevention: Below are some of the best practices suggested to prevent this attack: Identify which data is sensitive according to regulatory requirements, or business needs. Don't store sensitive data unnecessarily. Make sure to encrypt all sensitive data at rest. Disable caching for responses that contain sensitive data. Apply required security controls as per the data classification. Do not use legacy protocols such as FTP and SMTP for transporting sensitive data. Store passwords using strong hashing algorithms. Always use authenticated encryption instead of just encryption. Avoid deprecated cryptographic functions and schemes, such as MD5, SHA1, etc. Mitigation using F5 Distributed Cloud Services: 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. 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, these types of cryptographic failures can be mitigated by configuring WAF on load balancer thereby preventing sensitive data exposure. For further information click the links below: OWASP - Cryptographic Failures Mitigation OWASP - Authentication Failures using F5 XC Mitigating OWASP Top 10 2021: A01 Broken Access attacksMitigating OWASP Web Application Risk: Software and Data Integrity Failures using F5 XC Platform
Overview: This article is a continuation of the series of articles on mitigation of OWASP Web Application vulnerabilitiesusing F5 Distributed Cloud platform (F5 XC). Introduction to OWASPSoftware and Data Integrity Failures: Automating the software release process using CI/CD pipelines has helped organizations to significantly speed up their product delivery, reduce cost, apply updates/fixes in a short span of time etc. But at times to match up with frequent releases/updates security best practices are overlooked allowing attackers to infiltrate into the deployment pipeline and inject their malicious code eventually exposing end users to risk. Software and data integrity failures is one of the newest categories added as part of OWASP Web App Top 10 list. This vulnerability 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. The above image depicts a possible attack scenario where the attacker comes up with an open-source repository embedding malicious code in it. As a part of an update, the compromised package is imported into the repository and is deployed in the production environment resulting a wide distribution of malicious code allowing attackers to sneak into the end user’s network. Insecure Deserialization: Before understanding insecure deserialization, we should first be aware of serialization and deserialization ‘Serialization’ is a process of converting objects or data structures into a convenient format to make its storage or transmission easier, it is used to preserve the current state of an object. On the other hand, ‘Deserialization’ is a process of reverting back the serialized output (byte stream) into its original form (object). Now as we know about Serialization & Deserialization, we can start discussing insecure deserialization and how this vulnerability can pose a security concern. Insecure Deserialization occurs when user inputs are deserialized by a website in an unsafe manner and attackers can take advantage of it by modifying serialized object content to misuse application logic for their benefit. It is also known as object injection vulnerability. Now, it's time to have a look at the demonstration attack scenario and find out how F5 XC platform can help to mitigate this security event. Demonstration: For the purpose of this demonstration, we have already hosted a vulnerable application (XVWA) in an instance and are using F5 XC HTTP Load Balancer (LB) to route client requests to our vulnerable application server. To find out the configuration steps for the HTTP LB in F5 XC console follow this document. Note: XVWA (Xtreme Vulnerable Web Application) is a buggy application written in PHP/MySQL for learning application security. For more information refer to the repository. Attack Scenario: As you can see from the above screenshot, serialized data is added as a query parameter in the URL as soon as the button is clicked which hints the possibility of insecure deserialization vulnerability. The below code snippet shows the web application’s implementation, as you can see in the code “unserialize()” method is used for unserializing user input parameter ‘r’ from the request, when unserialize method is called, “__wakeup()” method will automatically get triggered, “__wakeup()” method will check whether inject variable is set or not and performs an eval operation on inject value if “isset()” returns true. Now, as we know the flow of execution, we can manipulate user request by crafting a serialized input to perform command injection attack In the below code snippet, we have created same class, as we are aware that inject variable’s value will get executed as a PHP code, we have used system() method to execute OS commands on host operating system, at the end created an object of the class and printed serialized object value. Serialized data explanation: [“O:18:"PHPObjectInjection":1:{s:6:"inject";s:17:"system('ps -ef'); ";}”] ‘O’ - Stands for Object, ‘18’ - Length of class name, ‘PHPObjectInjection’ - Class name, ‘1’ – Number of variables inside the class, ‘s’ – String, ‘6’ - Length of variable name, ‘inject’ – Variable name, ‘s’ – String, ‘17’ – Length of command, ‘system('ps -ef'); ";}’ - Command Now, as we have custom serialized data, we can use it to perform command injection attack. Below screenshot displays successful exploitation of vulnerability, as we got the list of running processes inside the server. Prevention: Step1: Login to F5 XC console and open the configuration page of your HTTP LB Step2: Enable Web Application Firewall (WAF), create/configure WAF policy as per your need and add it to your LB. For this demonstration we did the configuration as below: Step3: Repeat the attack scenario As you can see from the above screenshot, the F5 XC WAF engine has successfully identified and mitigated the attack which could otherwise have impacted adversely. At the end, monitor F5 XC Security Event Logs to get the details about the blocked attack Conclusion: With the ever-evolving threat landscape it has become critically important to securely manage your deployments. F5 XC security solution suite can help to achieve the same in a super simplified manner, as we have seen in the demonstration it only requiresadding adefault WAF policy in blocking mode to defeat the demo attack scenario. References: PHP methods used: isset(): It determines if a variable is declared and is different than null. For more information refer to the documentation eval(): It evaluates string as PHP code. For more information refer to the documentation system(): It can be used to execute OS commands and display the output. For more information refer to the documentation serialize(): It generates a storable representation of value. For more information refer to the documentation unserialize(): It creates a php value from stored representation. For more information refer to the documentation Magic Methods: They are the special methods which will override PHP's default action when certain actions are performed on an object (__wakeup() is one of the magic methods which will be called automatically when object is unserialized). For more information refer to the documentation For more details, follow below links: OWASP Top 10 - 2021 F5 Distributed Cloud WAAP Overview of OWASP Web Application Top 10 2021
