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: 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 DVWAMitigating OWASP Web Application Risk: Security Misconfiguration using F5 XC Platform
Overview: This article is a continuation of the series of articles on mitigation of OWASP Web App Top 10 vulnerabilities using F5 Distributed Cloud platform (F5 XC). Introduction to OWASP Security Misconfiguration: Security Misconfiguration is a vulnerability that occurs when security best practices are overlooked allowing attackers to get into the system utilizing the loopholes. The severity of this risk can be identified by the fact that it moved one step up from 6th position in the previous edition of OWASP top 10 (2017) to 5th position in the current edition (2021). A4:2017-XML External Entities (XXE), which was previously a separate category of risk, is now a part of security misconfiguration. Below are a few sample scenarios which highlight that the application might be vulnerable to security misconfiguration: Unnecessary features like ports, pages, privileges or services are enabled or installed. Default accounts and their passwords remain unchanged. Over sharing information while doing error handling. Forget to apply security patches. Vulnerable to XXE attacks. Demonstration: In this demonstration we will see how we can exploit the XXE vulnerability in ‘Mutillidae’ application and later steps to prevent it by using F5 Distributed Cloud Web App and API Protection (WAAP). Note: Mutillidae is a free and opensource web application that is deliberately designed to be vulnerable and is used for web security training. For more details you can refer OWASP Mutillidae II documentation. Introduction to XXE (XML eXternal Entity): XXE attack targets an application that parses XML input. This attack occurs when a weakly configured XML parser processes XML input containing a reference to an external entity. Step by step process: In the below steps we will first set the enforcement mode as ‘Monitoring’ in the app firewall policy, perform the attack and observe security event logs. This will give us an idea about the application vulnerability and WAF engine efficiency in detecting the threat, and at a later stage we will set the enforcement mode as ‘Blocking’, to let the WAF engine block any such malicious request in future. Step1: Create a Load Balancer (LB) in F5 Distributed Cloud console and add the application server as an origin pool member. Refer to F5 Distributed Cloud docs for configuration steps. Step2: Create a WAF policy with enforcement mode as ‘Monitoring’ and add it to your LB Select WAAP service from Distributed Cloud console homepage. Navigate to Manage->App Firewall, click ‘Add App Firewall’. Enter a name, select ‘Enforcement Mode’ as ‘Monitoring’, click ‘Save & Exit’. Navigate to Manage->Load Balancers->HTTP Load Balancer. On the right side of your LB click on three dots (ellipsis) and select ‘Manage Configuration’ as an action, click on ‘Edit Configuration’. Scroll down, in ‘Security Configuration’, ‘Enable’ WAF (Web Application Firewall) and select the app firewall created. Click ‘Save & Exit’. Step3: Identify and exploit the XXE vulnerability of the application and monitor the security events logs in Distributed Cloud console. Note: Among various types of XXE attacks, we have chosen one to retrieve the contents of a file (/etc/passwd) containing information related to the users on the system like username, user id etc. from the server’s file system. Step4: Modify the enforcement mode of the firewall policy to ‘Blocking’ Step5: Repeat Step3. and blocked by the Distributed Cloud WAF engine. Conclusion: As you can see from the demonstration, the F5 Distributed Cloud WAF engine was able to successfully detect and restrict the attempt to exploit the XXE vulnerability. Reference Link: Overview of OWASP Web Application Top 10 2021Mitigating OWASP Web Application Risk: Vulnerable & Outdated Components using F5 XC Platform
Introduction to OWASP TOP 10 2021: The Overview article on mitigation of OWASP Top 10 Application Security risk categories using F5 Distributed Cloud Web App and API Protection (WAAP) covered details about OWASP & mitigation strategy for Injection attacks followed by 3 more articles in sequence covering Broken Access, Authentication and Cryptographic Failures, Security Misconfiguration (check reference links at the end of this article for more details). This article is in continuation of the series and will cover A06:2021 – Vulnerable and Outdated Components. Introduction to Vulnerable and Outdated Components: Vulnerable and Outdated Components was in 2017 OWASP Top 10 list with a name of “Components with Know Vulnerabilities” and has secured a better position now from #9 to #6 in 2021 OWASP Top 10 list. Applications used in enterprises often contain open-source components such as libraries and frameworks (e.g., Junit, Log4J, SonarQube, Open SSL). Such applications 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. Since numerous computer program components run with the same privileges as the application itself, any vulnerabilities or imperfections within such components can result in a danger to the software/application. Utilizing components which are prone to vulnerabilities makes the application vulnerable to attacks that target any portion of the application stack which makes the security of the application unstable causing threat to the organization’s security. Using F5 Distributed Cloud Web Application Firewall (F5 XC WAF) we can identify these vulnerabilities and prevent the impact by configuring the WAF. Demonstration: In this demonstration we will exploit one of the vulnerabilities of PHP server, admin console page (phpMyAdmin.php) which has sensitive info related to the backend server like homepage location, user info and relative credentials etc. For the demo, we are using ‘Mutillidae’ vulnerable application as the backend server (check reference links for more details). We will also see the detailed prevention steps using Distributed Cloud WAAP. Steps: In this process, we will configure the enforcement mode as ‘Monitoring’ in the application firewall policy, exploit the vulnerability and will observe the security event log so that we will come to know how the WAF engine is efficiently identifying the threats. Create a Load Balancer (LB) in Distributed Cloud console and add the Mutillidae application as an origin pool member, Refer F5 Distributed Cloud Tech Docs for configuration steps. Create a firewall policy with enforcement mode as ‘Monitoring’ and add it to your LB Select WAAP service from Distributed Cloud console homepage. Navigate to Manage->App Firewall, click ‘Add App Firewall’ Enter a name, select ‘Enforcement Mode’ as ‘Monitoring’, click ‘Save & Exit’ Navigate to Manage->Load Balancers->HTTP Load Balancer. On the right side of your LB click on three dots (ellipsis) and select ‘Manage Configuration’ as an action, click on ‘Edit Configuration’ Scroll down, in ‘Security Configuration’, ‘Enable’ WAF (Web Application Firewall) and select the firewall created. Click ‘Save & Exit’ Access the above-mentioned vulnerable PHP server admin page (phpmyadmin.php) and monitor the security event logs. The above screenshot will show you the admin page that provides sensitive information related to database server which should not be exposed to the outside world. Security Event Logs: To verify the logs, Select Web application & API Protection (WAAP) service from Distributed Cloud console homepage. Navigate to Overview --> Dashboard, click on ‘Security Events’ Since the WAF is in monitoring mode the WAF engine has detected and allowed the PHP admin vulnerability as shown below. The above screenshot shows the PHP vulnerability signature details with matching info of the security event. Modify the enforcement mode of the firewall policy created to ‘Blocking’ as below Repeat Step3. In the above screenshot you can see how the Distributed Cloud WAF engine has successfully detected and blocked the known vulnerability. Security Event Logs: Refer step-3 to navigate to dashboard Since the WAF is in blocking mode the WAF engine has detected and blocked the PHP admin vulnerability as shown below. In the above screenshot you can see the php admin page attack has been successfully identified and blocked by Distributed Cloud WAF engine. Conclusion: As you can see from the demonstration, the F5 Distributed Cloud WAF was successfully able to detect and restrict the attempt to exploit the known vulnerability of php admin page, a part of vulnerable and outdated components category. For further information click the links below: OWASP Vulnerable and Outdated Component OWASP Mutillidae II documentation F5 Distributed Cloud WAAPMitigating OWASP Web Application Risk: Security Logging & Monitoring Failures using F5 XC Platform
Overview: The overview article covered 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 may not 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 elaborative way 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 aggregating for 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 templates and 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_Failures
How to deploy a basic OWASP Top 10 for 2021 compliant declarative WAF policy for BIG-IP (Part 2)
This article follows up the excellent article written by Valentin_Tobi on the same subject based on OWASP Top 10 2017. I will borrow heavily from the original and update this where changes have been made. This is part 2, where I will cover the OWASP compliance dashboard and the declarative code to bring our application into OWASP compliance. If you missed part 1 Click here The Declarative Advanced WAF policies are security policies defined using the declarative JSON format, which facilitates integration with source control systems and CI/CD pipelines. The documentation of the declarative WAF policy (v17.0) can be found here while its schema can be consulted here. Where relevant, I will show a snippet of code to represent what we are securing. The entire policy can be found here. One of the most basic Declarative WAF policies that can be applied is as follows: { "policy": { "name": "OWASP_2021", "description": "Rapid Deployment Policy", "template": { "name": "POLICY_TEMPLATE_RAPID_DEPLOYMENT" } } As you can see from the OWASP Compliance Dashboard screenshot, this policy is far from being OWASP-compliant, but we will use it as a starting point to build a fully compliant configuration. This article will go through each vulnerability class and show an example of declarative WAF policy configuration that would mitigate that respective vulnerability. Attack signatures are mentioned in numerous categories, I will just cover and mention them once as to not be redundant. Broken access control (A1) As K44094284: Securing against the OWASP Top 10 for 2021 | Chapter1: Broken access control (A1) states: "Broken access control occurs when an issue with the access control enforcement allows a user to perform an action outside of the user's limits. For example, an attacker may be able to exploit a flaw in an application with the intention of gaining elevated access to a protected resource to which they are not entitled. As a result of the privilege escalation, the attacker can perform unauthorized actions.” Securing against Broken access controls entails configuring attack signatures, allowed and disallowed URLs, URLs flow enforcement, Disallowed file types and Entities. }, "enforcementMode":"transparent", "protocolIndependent": true, "caseInsensitive": true, "general": { "trustXff": true }, "signature-settings":{ "signatureStaging": false, "minimumAccuracyForAutoAddedSignatures": "high" }, Cryptographic failures (A2) According to K00174750: Securing against the OWASP Top 10 for 2021 | Chapter 2: Cryptographic failures (A2): “Attackers often target sensitive data, such as passwords, credit card numbers, and personal information, when you do not properly protect them. Cryptographic failure is the root cause for sensitive data exposure. According to the Open Web Application Security Project (OWASP) 2021, securing your data against cryptographic failures has become more important than ever. A cryptographic failure flaw can occur when you do the following: Store or transit data in clear text (most common) Protect data with an old or weak encryption Improperly filter or mask data in transit.” Mitigation's include Attack Signatures, Data Guard and Masked log values. BIG-IP Advanced WAF can protect sensitive data from being transmitted using Data Guard response scrubbing and from being logged with request log masking: "data-guard": { "enabled": true }, To get this score you must also enable SSL Encryption on both the client-side and server-side. Injection (A3) According to K13570030: Securing against the OWASP Top 10 for 2021 | Chapter 3: Injection (A3): “Injection attacks are one of the most dangerous attacks where an attacker simply sends malicious data to make the application process it and do something it is not supposed to do. Injection vulnerabilities are prevalent, especially in legacy code that does not validate or sanitize user-supplied input. Common application technologies that may be victims of an injection attack are the following: SQL NoSQL Lightweight Directory Access Protocol (LDAP) XPath Operating system commands XML parsers SMTP headers Attackers typically exploit injection flaws by injecting an operating system command, SQL query, or even a full script into a parameter, header, URL, other form of data that an application receives.” To protect your application, best practices recommend that you configure F5 products to inspect and validate all user-supplied input to your applications against known attack signatures, evasion techniques, and other known attributes/parameters. Insecure Design (A4) As per K39707080: Securing against the OWASP Top 10 for 2021 | Chapter 4: Insecure design (A4): “Insecure design is focused on the risks associated with flaws in design and architecture. It focuses on the need for threat modeling, secure design patterns, and principles. The flaws in insecure design are not something that can be rectified by an implementation. OWASP differentiates insecure design from security implementation and controls as follows: An insecure design cannot be fixed by a perfect implementation as by definition, needed security controls were never created to defend against specific attacks. To protect your applications against insecure design, you should use the following best practices when designing your applications: Analyze use cases together with misuse cases when defining the user stories. Define security rules, checks, and access controls in each user story. Use threat-modelling assessment process per each component and feature. Write unit and integration tests to validate that all critical flows are resistant to the threat model. Design tenant isolation in all layers. Limit resource consumption per user and service. Security misconfiguration (A5) According to K49812250: Securing against the OWASP Top 10 for 2021 | Chapter 5 Security misconfiguration (A5): “Security misconfiguration vulnerabilities occur when a web application component is susceptible to attack due to a misconfiguration or insecure configuration option. Misconfiguration vulnerabilities are configuration weaknesses that may exist in software components and subsystems or in user administration. For example, web server software may ship with default user accounts that an attacker can use to access the system, or the software may contain sample files, such as configuration files and scripts that an attacker can exploit. In addition, software may have unneeded services enabled, such as remote administration functionality. Misconfiguration vulnerabilities make your application susceptible to attacks that target any part of the application stack. For example, the following attack types may target misconfiguration vulnerabilities: Brute force/credential stuffing Code injection Buffer overflow Command injection Cross-site scripting (XSS) Forceful browsing XML external entity attacks Security misconfiguration in OWASP 2021 also includes XML external entity attacks. XXE attack is an attack against an application that parses XML input. The attack occurs when a weakly configured XML parser processes XML input containing a reference to an external entity. XXE attacks exploit document type definitions (DTDs), which are considered obsolete; however, they are still enabled in many XML parsers. Note: the policy already has a list of disallowed file types configured by default. Vulnerable and outdated components (A6) As per K17045144: Securing against the OWASP Top 10 for 2021 | Chapter 6: Vulnerable and outdated components (A6): “Component-based vulnerabilities occur when a software component is unsupported, out of date, or vulnerable to a known exploit. You may inadvertently use vulnerable software components in production environments, posing a threat to the web application.” Using components with known vulnerabilities makes your application susceptible to attacks that target any part of the application stack. For example, the following attack types are a few that may target known component vulnerabilities: Code injection Buffer overflow Command injection Cross-site scripting (XSS) F5 products provide security features, such as attack signatures, that protect your web application against component-based vulnerability attacks. In addition, F5 provides tools, such as the F5 iHealth diagnostic tool, that allows you to audit BIG-IP software components and their dependencies, making sure that the components are up-to-date and do not contain known vulnerabilities. Identification and authentication failures (A7) According to K14998322: Securing against the OWASP Top 10 for 2021 | Chapter 7 Identification and authentication failures (A7): “Identification and authentication failures can occur when functions related to a user's identity, authentication, or session management are not implemented correctly or not adequately protected by an application. Attackers may be able to exploit identification and authentication failures by compromising passwords, keys, session tokens, or exploit other implementation flaws to assume other users' identities, either temporarily or permanently. F5 products provide control mechanisms to mitigate and protect against attacks that attempt to exploit broken authentication. Attackers use a range of techniques to exploit broken authentication, including the following: Brute force/credential stuffing Session hijacking Session fixation Cross Site Request Forgery (CSRF) Execution After Redirect (EAR) One-click attack The BIG-IP Advanced WAF/ASM system provides the following controls to protect your application against identification and authentication failures, Attack signatures, Session hijacking protection, Cookie encryption, Brute force protection, Credential stuffing protection, CSRF protection and Login enforcement. }, "brute-force-attack-preventions": [ { "bruteForceProtectionForAllLoginPages": true, "leakedCredentialsCriteria": { "action": "alarm-and-blocking-page", "enabled": true } } ], "csrf-protection": { "enabled": true }, "csrf-urls": [ { "enforcementAction": "verify-csrf-token", "method": "GET", "url": "/trading/index.php" Software and data integrity (A8) As per K50295355: Securing against the OWASP Top 10 for 2021 | Chapter 8: Software and data integrity (A8): “Software and data integrity failures relate to code and infrastructure that does not protect against integrity violations. This can occur when you use software from untrusted sources and repositories or even software that has been tampered with at the source, in transit, or even the endpoint cache. Attackers can exploit this to potentially introduce unauthorized access, malicious code, or system compromise as part of the following attacks: Cache Poisoning Code injection Command execution Denial of Service You can use BIG-IP Advanced WAF/ASM to mitigate software and data integrity failures by using the following guidance: Attack Signatures, Enforced cookies and Content profiles. Security logging and monitoring failures (A9) According to K94068935: Securing against the OWASP Top 10 for 2021 | Chapter 9: Security logging and monitoring failures (A9) “Security logging and monitoring failures are frequently a factor in major security incidents. The BIG-IP system includes advanced logging and monitoring functionality and provides security features to protect against attacks that can result from insufficient system and application logging and monitoring. Failure to sufficiently log, monitor, or report security events, such as login attempts, makes suspicious behavior difficult to detect and significantly raises the likelihood that an attacker can successfully exploit your application. For example, an attacker may probe your application or software components for known vulnerabilities over a period. Allowing such probes to continue undetected increases the likelihood that the attacker ultimately finds a vulnerability and successfully exploits the flaw. Insufficient logging, monitoring, or reporting makes your application susceptible to attacks that target any part of the application stack. For example, the following attack types may result from a failure to log, monitor, or report security events: Code injection Buffer overflow Command injection Cross-site scripting (XSS) Forceful browsing This configuration is not part of the declarative WAF policy so it will not be described here - please follow the instructions in the referred article. Once logging has been configured, check the relevant items in the OWASP Compliance Dashboard. Server-side request forgery (SSRF) (A10) According to K36263043: Securing against the OWASP Top 10 for 2021 | Chapter 10: Server-side request forgery (SSRF): Server-side request forgery (SSRF) flaws occur whenever a web application is fetching a remote resource without validating the user-supplied URL. The vulnerable web application will often have privileges to read, write, or import data using a URL. To execute an SSRF attack, the attacker abuses the functionality on the server to read or update internal resources. The attacker can then force the application to send requests to access unintended resources, often bypassing security controls. Use SSRF protection (BIG-IP Advanced WAF 16.1.0 and later). Identify parameters of data type URI that are subjected to SSRF attack and explicitly define the URI parameters in your security policy or use the Auto-detect Parameter feature to automatically detect URI parameters in your application. From these parameters, identify the specific hosts to which you want disallow access, and, in your security policy under Advanced Protection, for SSRF Protection, add these specific hosts (IP addresses or host names) to the SSRF Hosts list. Conclusion This article has shown a very basic OWASP Top 10 for 2021 - compliant declarative WAF policy. It worth noting that, although this WAF policy is fully compliant to OWASP Top 10 recommendations, it contains elements that need to be customised for each individual application and should only be treated as a starting point for a production-ready WAF policy that would most likely need to be additional configuration. Many sections have items that need to be configured manually and/or policies and procedures need to be implemented to become compliant. The F5 OWASP dashboard shows the requirement, then allows you to manually indicate you are compliant for the dashboard to show complete. The full configuration of the declarative policy used in this example can be found on CodeShare: Example OWASP Top 10-compliant declarative WAF policyExample OWASP Top 10-compliant declarative WAF policy
Problem this snippet solves: This is an example of a basic declarative BIG-IP WAF policy that is OWASP Top 10-compliant. This policy can be used as a starting point for a production-ready version. A companion Dev Central article discussing this policy in depth can be found here. How to use this snippet: This policy can be deployed through an AS3 declaration to the BIG-IP. Code : { "policy": { "name": "Complete_OWASP_Top_Ten", "description": "A basic, OWASP Top 10 protection items v1.0", "template": { "name": "POLICY_TEMPLATE_RAPID_DEPLOYMENT" }, "enforcementMode":"transparent", "protocolIndependent": true, "caseInsensitive": true, "general": { "trustXff": true }, "signature-settings":{ "signatureStaging": false, "minimumAccuracyForAutoAddedSignatures": "high" }, "blocking-settings": { "violations": [ { "alarm": true, "block": true, "description": "ASM Cookie Hijacking", "learn": false, "name": "VIOL_ASM_COOKIE_HIJACKING" }, { "alarm": true, "block": true, "description": "Access from disallowed User/Session/IP/Device ID", "name": "VIOL_SESSION_AWARENESS" }, { "alarm": true, "block": true, "description": "Modified ASM cookie", "learn": true, "name": "VIOL_ASM_COOKIE_MODIFIED" }, { "name": "VIOL_LOGIN_URL_BYPASSED", "alarm": true, "block": true, "learn": false }, { "alarm": true, "block": true, "description": "XML data does not comply with format settings", "learn": true, "name": "VIOL_XML_FORMAT" }, { "name": "VIOL_FILETYPE", "alarm": true, "block": true, "learn": true }, { "name": "VIOL_URL", "alarm": true, "block": true, "learn": true }, { "name": "VIOL_URL_METACHAR", "alarm": true, "block": true, "learn": true }, { "name": "VIOL_PARAMETER_VALUE_METACHAR", "alarm": true, "block": true, "learn": true }, { "name": "VIOL_PARAMETER_NAME_METACHAR", "alarm": true, "block": true, "learn": true } ], "evasions": [ { "description": "Bad unescape", "enabled": true, "learn": true }, { "description": "Apache whitespace", "enabled": true, "learn": true }, { "description": "Bare byte decoding", "enabled": true, "learn": true }, { "description": "IIS Unicode codepoints", "enabled": true, "learn": true }, { "description": "IIS backslashes", "enabled": true, "learn": true }, { "description": "%u decoding", "enabled": true, "learn": true }, { "description": "Multiple decoding", "enabled": true, "learn": true, "maxDecodingPasses": 3 }, { "description": "Directory traversals", "enabled": true, "learn": true } ] }, "session-tracking": { "sessionTrackingConfiguration": { "enableTrackingSessionHijackingByDeviceId": true } }, "urls": [ { "name": "/trading/auth.php", "method": "POST", "protocol": "https", "type": "explicit" }, { "name": "/internal/test.php", "method": "GET", "protocol": "https", "type": "explicit", "isAllowed": false }, { "name": "/trading/rest/portfolio.php", "method": "GET", "protocol": "https", "type": "explicit", "urlContentProfiles": [ { "headerName": "Content-Type", "headerValue": "text/html", "type": "json", "contentProfile": { "name": "portfolio" } }, { "headerName": "*", "headerValue": "*", "type": "do-nothing" } ] } ], "login-pages": [ { "accessValidation": { "headerContains": "302 Found" }, "authenticationType": "form", "passwordParameterName": "password", "usernameParameterName": "username", "url": { "name": "/trading/auth.php", "method": "POST", "protocol": "https", "type": "explicit" } } ], "login-enforcement": { "authenticatedUrls": [ "/trading/index.php" ] }, "brute-force-attack-preventions": [ { "bruteForceProtectionForAllLoginPages": true, "leakedCredentialsCriteria": { "action": "alarm-and-blocking-page", "enabled": true } } ], "csrf-protection": { "enabled": true }, "csrf-urls": [ { "enforcementAction": "verify-csrf-token", "method": "GET", "url": "/trading/index.php" } ], "data-guard": { "enabled": true }, "xml-profiles": [ { "name": "Default", "defenseAttributes": { "allowDTDs": false, "allowExternalReferences": false } } ], "json-profiles": [ { "name": "portfolio" } ], "policy-builder-server-technologies": { "enableServerTechnologiesDetection": true } } } Tested this on version: 16.0Mitigating 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 or providing 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 WAF
