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 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_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 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 WAFMitigating OWASP Web Application Risk: Injection exploits using F5 Distributed Cloud Platform
This article is in continuation of the owasp web application security series and is intended to give insights into injection attack category. Check here for overview article. Introduction to Injection vulnerability: An application is vulnerable to attack when: Provided data is not validated by the application. User requested schema is not being analyzed before processing. Data is used within search parameters to extract additional and sensitive records. SQL commands are used in dynamic queries and commands. If user tries to use Cross-site Scripting to get some unauthorized data. Some of the common injections are SQL, NoSQL, OS command, Object Relational Mapping (ORM), Etc. Step by step process: Version: Cloud Console at the time of article: crt-20220510-1579 Step1: Login to distributed cloud console and navigate to Load balancers menu, then expand “Security” section and then click on “App Firewall” Step2: Click “Add App Firewall” button and provide some name. Keep default options and save new firewall. Step3: Navigate to Manage section and select “HTTP Load Balancers” in load balancers drop-down option. Step4: Select 3 dots available in Action column besides your application load balancer and select “Manage Configuration”. Step5: In top right corner click on “Edit Configuration” button and navigate to “Security Configuration” section available on left menu. Step6: Disable service policies, Bot-Defense and Rate-Limiting features. In WAF config section enable App Firewall and select your firewall created in Step2. “Save and Exit” the load balancer dialog. Step7: Copy the load balancer domain, open a browser and open the copied domain. Validate you can access your application. Step8: Next in browser URL, click on Sign-in button, add SQL injection attack script “or '1'='1” in email field, some random password and click on “Confirm” button. Validate your application is still accessible and request is not blocked with message of invalid email address. Step9: In cloud console page navigate to “Virtual Hosts” section and then select HTTP Load Balancers. Select “Security Monitoring” link for your application load balancer. In Dashboard validate new security events are generated with your IP and location. Navigate to the Security Events section and check the latest log request details. Solution: To mitigate these injection attacks, navigate to Firewall section and in “App Firewall” configuration change “Enforcement Mode” to Blocking, keep default options in other fields and save firewall. Next in browser try to pass above same SQL injection attack in username field of Sign-in page, validate your request is blocked and support-id is displayed in response as below: In Distributed Cloud Console navigate to security events section, expand the latest requests, filter logs with your request-ID and validate you can see the request log as below: Conclusion: As shown above, OWASP Top 10: Injection attacks can be mitigated by configuring WAF firewall in Blocking mode thereby preventing data breaches and even application downtime. Stay tuned for more exciting details on how F5 Distributed Cloud can protect your web applications against other OWASP top ten vulnerabilities. For further information click the links below: OWASP Top 10 - 2021 Configuring load balancer in cloud console Security features in cloud console Steps to delegate domain in cloud consoleMitigating 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: Identification and Authentication Failures using F5 XC
Introduction to OWASP: Introduction article covered details of OWASP 2nd article covered broken access attacks This 3rd article is in continuation of the series which will cover Identification and Authentication Failures. Introduction to Identification and Authentication Failures: In our daily activities confirmation of the user's identity, authentication, authorization and session management is critical to protect against authentication-related attacks. There may be authentication weaknesses if the application: Permits automated attacks such as credential stuffing, where the attacker has a list of valid usernames and passwords. Permits brute force or other automated attacks. Permits default, weak, or well-known passwords, such as "password", “default” or "admin". Uses plain text, encrypted, or weakly hashed passwords data store. Introduction to credential stuffing: This is the common attack attackers typically use with lists of known passwords with automation tools like Selenium, Postman, etc. and get authenticated. Suppose an application does not implement automated threat or credential stuffing protection, attacker can exploit the login page using this credential stuffing attack. Step by step process: Step1: Please follow steps as per link to configure HTTP load balancer. Do not configure any security policies or bot-defense on this load balancer. Step2: Develop a selenium script to automate UI login page which uses credentials from creds.csv file as below: from selenium import webdriver import random import string import os import csv import sys import argparse import time driver = webdriver.Chrome("chromedriver.exe") parser = argparse.ArgumentParser() parser.add_argument("--backend", help="Use the unprotected backend airline app", action="store_true") args = parser.parse_args() if args.backend: target = 'https://jbair.f5-hyd-demo.com/user/signin' else: target = 'https://jbair.f5-hyd-demo.com/user/signin' def loginuser(name, password): driver.get(target) driver.find_element_by_xpath('/html/body/div[2]/div/form/div[1]/input').send_keys(name) driver.find_element_by_xpath('/html/body/div[2]/div/form/div[2]/input').send_keys(password) driver.find_element_by_xpath('/html/body/div[2]/div/form/button').click() f = open('creds.csv') csv = csv.reader(f) for row in csv: print (row[0]) print (row[1]) if loginuser(row[0], row[1]) is True: break time.sleep(1) driver.close() Step3: Execute the above script to generate credential stuffing attack and to identify if anyone of the provided credentials is working. In above steps we have seen how hackers were able to find valid credentials from large combinations of leaked passwords using simple automation scripts. Prevention: Below are some of the best practices suggested to prevent this credential stuffing attack: Multi Factor Authentication Secondary passwords Captcha solving Rate limiting requests Auditing failed logins Mitigation using F5 distributed cloud: Please follow steps as per link to configure bot defense on load balancer. Make sure configurations are correct and mitigation action is set to Block as below: Rerun the above script again and validate your request is blocked as below. In Security monitoring Section, Navigate to Bot defense section to check the overview of bot defense. As shown below dashboard shows selenium bot type detected as threat intelligence. It also gave details about endpoints, Humans & Bot request counts and IP where bot requests were generated. Navigate to Requests and Bot traffic overview tabs to understand the reason why requests were blocked as below: Conclusion: As shown above, brute force attacks can be mitigated by configuring Bot-Defense on load balancer thereby preventing forceful browsing and credential stuffing. For further information click the links below: OWASP - Authentication Failures F5 XC Bot-Defense Introduction Credential Stuffing mitigation
