Mitigating 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: 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. 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 2021
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 policyMitigating 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 DVWAHow to deploy a basic OWASP Top 10 for 2021 compliant declarative WAF policy for BIG-IP
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. Due to length of this article, I will split this into parts to more easily digest. Part 1 will cover what is OWASP Top 10 for 2021 and what are the key changes. Part 2 will cover the OWASP Compliance dashboard in BIG-IP and what code we will use to bring our device into compliance. This article describes an example of a minimal declarative WAF policy that is OWASP Top 10 compliant. Note that there are policy elements that are customized for the application being protected, in this case a demo application named Arcadia Finance, so they will need to be adapted for each application. The policy was configured following the pattern described in K45215395: Securing against the OWASP Top 10 for 2021 guide and its conformance with OWASP Top 10 is being verified by consulting the OWASP Compliance Dashboard bundled with F5's Advanced WAF. OWASP Top 10 2021 introduction and key changes from 2017 As described in K45215395: Securing against the OWASP Top 10 for 2021, the current OWASP Top 10 for 2021 vulnerabilities are: Broken access control (A1) moves up from the fifth position; 94% of applications were tested for some form of broken access control. Cryptographic failures (A2) shifts up one position to #2, previously known as Sensitive data exposure. Injection (A3) slides down to the third position. 94% of the applications were tested for some form of injection. Insecure design (A4) is a new category for 2021. Insecure design is focused on the risks associated with flaws in design and architecture. To exploit insecure design, attackers can threat model workflows in the software to reveal a broad range of vulnerabilities and weaknesses. Security misconfiguration (A5) moves up from #6 --The former category for XML External Entities (XXE) is now part of this category. Vulnerable and outdated components (A6) Component-based vulnerabilities occur when a software component is unsupported, out of date, or vulnerable to a known exploit. Identification and authentication failures (A7) was previously Broken Authentication. 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. Software and data integrity failures (A8) is a new category for 2021. Software and data integrity failures relate to code and infrastructure that does not protect against integrity violations. Attackers can exploit these failures to introduce unauthorized access, malicious code, or complete system compromise. Security logging and monitoring failures (A9) was previously Insufficient Logging & Monitoring. Insufficient logging, monitoring, or reporting makes your application susceptible to attacks that target any part of the application stack. Server-side request forgery (SSRF) (A10) Server-side request forgery (SSRF) flaws occur when a web application fetches a remote resource without validating the user-supplied URL. To execute an SSRF attack, the attacker abuses the functionality on the server to read or update internal resources. Most of these vulnerabilities can be mitigated with a properly configured WAF policy while, for the few of them that depend on security measures implemented in the application itself, there are recommended guidelines on application security which will prevent the exploitation of OWASP 10 vulnerabilities. In the follow-on article, I will cover the declarative WAF policies and the effect they have on the BIG-IP Advanced WAF. HereA basic OWASP 2017 Top 10-compliant declarative WAF policy
As OWASP Application Security Risks Top 10 is the most recognized report outlining the top security concerns for web application security, it is important to see how to configure F5's declarative Advanced WAF policy to protect against those threats. This article describes an example of a basic declarative WAF policy that is OWASP 2017 Top 10-compliant. Note that there are policy entities that are customized for the application being protected, in this case a demo application named Arcadia Finance so they will need to be adapted for each particular application to be protected. The policy was configured following the pattern described in K52596282: Securing against the OWASP Top 10 guide and its conformance with OWASP Top 10 is being verified by consulting the OWASP Compliance Dashboard bundled with F5's Advanced WAF. Introduction As described in the above K52596282: Securing against the OWASP Top 10, the current OWASP Top 10 vulnerabilities are: Injection attacks (A1) Broken authentication attacks (A2) Sensitive data exposure attacks (A3) XML external entity attacks (A4) Broken access control attacks (A5) Security misconfiguration attacks (A6) Cross-site scripting attacks (A7) Insecure deserialization attacks (A8) Components with known vulnerabilities attacks (A9) Insufficient logging and monitoring attacks (A10) Most of these vulnerabilities can be mitigated with a properly configured WAF policy while, for the few of them that depend on security measures implemented in the application itself, there are recommended guidelines on application security which will prevent the exploitation of OWASP 10 vulnerabilities. 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 (v16.0) can be found here while its schema can be consulted here. One of the most basic declarative Advanced WAF policies that can be applied is as follows: { "policy": { "name": "Complete_OWASP_Top_Ten", "description": "A basic, OWASP Top 10 protection items v1.0", "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. Injection attacks (A1) As K51836239: Securing against the OWASP Top 10 | Chapter 2: Injection attacks (A1) states: "An injection attack occurs when: An attacker injects a command, query, or code into a vulnerable element of the application. The web application server executes the injection. The attacker gains unauthorized access, causes a denial of service, steals sensitive data, or causes a similarly nefarious outcome." Securing against injection attacks entails configuring attack signatures and evasion techniques as well as restricting meta characters and parameters. The following configuration, added to the above basic declarative policy, will meet those requirements: "signature-settings":{ "signatureStaging": false, "minimumAccuracyForAutoAddedSignatures": "high" }, "blocking-settings": { "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 } ] } Broken authentication attacks (A2) According to K35371357: Securing against the OWASP Top 10 | Chapter 3: Broken authentication (A2): "The Open Web Application Security Project (OWASP) defines broken authentication as incorrect implementation of application functions related to authentication and session management. Using broken authentication, attackers can compromise passwords, keys, or session tokens, or exploit other implementation flaws to assume other users' identities, either temporarily or permanently." Mitigations include session hijacking protection and tracking user sessions, brute force protection, credential stuffing protection and CSRF protection. Here is an example of configuration that will enable those features: "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 } ], "evasions": [ <...> ] }, "session-tracking": { "sessionTrackingConfiguration": { "enableTrackingSessionHijackingByDeviceId": true } }, "urls": [ { "name": "/trading/auth.php", "method": "POST", "protocol": "https", "type": "explicit" } ], "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" } ] Note: this is a configuration example customized for Arcadia Finance demo application. The URLs specified in your configuration might be different. Sensitive data exposure (A3) According to K05354050: Securing against the OWASP Top 10 | Chapter 4: Sensitive data exposure (A3): "A sensitive data exposure flaw can occur when you: Store or transit data in clear text (most common). Protect data with an old or weak encryption. Do not properly filter or mask data in transit." BIG-IP Advanced WAF can protect sensitive data from being transmitted using Data Guard response scrubbing and from being logged with request log masking. Note: masking sensitive data in the request log is enabled by default. You can enable Data Guard by adding the following configuration to the policy: "data-guard": { "enabled": true } XML external entity attacks (A4) As per K50262217: Securing against the OWASP Top 10 | Chapter 5: XML external entity attacks (A4): "According to the Open Web Application Security Project (OWASP), an 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." Securing against XXE can be done through disallowing DTDs and enabling XXE attack signatures. The following configuration achieves that: "blocking-settings": { "violations": [ <...> { "alarm": true, "block": true, "description": "XML data does not comply with format settings", "learn": true, "name": "VIOL_XML_FORMAT" } ], "evasions": [ <...> ] }, "xml-profiles": [ { "name": "Default", "defenseAttributes": { "allowDTDs": false, "allowExternalReferences": false } } ] Note: XXE attack signatures are enabled by default. Broken access control (A5) According to K36157617: Securing against the OWASP Top 10 | Chapter 6: Broken access control (A5): "Access control, also called authorization, allows or denies access to your application's features and resources. Misuse of access control enables: Unauthorized access to sensitive information. Inappropriate creation or deletion of resources. User impersonation. Privilege escalation." Preventing attacks exploiting broken access control can be done by login enforcement, enabling path traversal or authentication/authorization attack signatures and disallowing file types and URLs. For example, the following configuration will enable the disallowed file type and URL violations and add a disallowed URL: "blocking-settings": { <...> { "name": "VIOL_FILETYPE", "alarm": true, "block": true, "learn": true }, { "name": "VIOL_URL", "alarm": true, "block": true, "learn": true } ], "evasions": [ <...> ] }, "urls": [ <...> { "name": "/internal/test.php", "method": "GET", "protocol": "https", "type": "explicit", "isAllowed": false } ] Note: the policy already has a list of disallowed file types configured by default: Security misconfiguration attacks (A6) As per K10622005: Securing against the OWASP Top 10 | Chapter 7: Security misconfiguration attacks (A6): "Misconfiguration vulnerabilities are configuration weaknesses that may exist in software components or subsystems. 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." Since these vulnerabilities depend on the way the application has been configured, F5 has a number of recommendations for the system administrators describing some techniques used to mitigate this class of attacks - please see the referenced article. You can then check the relevant items under the OWASP Compliance Dashboard: Click "Review & Update" to apply the changes. Cross-site scripting (A7) According to K22729008: Securing against the OWASP Top 10 | Chapter 8: Cross-site scripting (A7): "Cross-site scripting (XSS or CSS) occurs when a web application receives untrusted data and then sends that data, without validation, to an end user's web browser. This transaction enables an attacker to send executable code to the victim’s browser and, ultimately, manipulate the end user's session by doing one of the following: Session hijacking Defacing the website Redirecting the user to a site with malicious intent (most common)" Securing against XSS attacks can be done by enabling the relevant attack signatures and disallowing meta-characters in parameters - the following demonstrates this configuration: "blocking-settings": { "violations": [ <...> { "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 } ] Insecure deserialization (A8) As per K01034237: Securing against the OWASP Top 10 | Chapter 9: Insecure deserialization (A8): "Serialization occurs when an application converts data structures and objects into a different format, such as binary or structured text like XML and JSON, so that it is suitable for other purposes, including the following: Data storage Messaging Remote procedure call (RPC)/inter-process communication (IPC) Caching HTTP cookies HTML form parameters API authentication tokens Deserialization is when an application reverts the serialized output into its original form. To exploit insecure deserialization, attackers typically tamper with the data in data structures or objects that modify an object's content or change an application's logic." Protecting against deserialization attacks can be done by performing HTTP header, XML or JSON validation and by enabling the insecure deserialization attack signatures - note that these signatures are enabled by default. An example of JSON validation configuration can be seen below: "urls": [ <...> { "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" } ] } ], "json-profiles": [ { "name": "portfolio" } ] Using components with known vulnerabilities (A9) According to K90977804: Securing against the OWASP Top 10 | Chapter 10: Using components with known vulnerabilities (A9): "Component-based vulnerabilities occur when a web application component is unsupported, out of date, or vulnerable to a known exploit. The BIG-IP ASM system provides security features, such as attack signatures, that protect your web application against component-based vulnerability attacks." As a way to customize the WAF policy for the server technologies relevant to your back-end, consider adding them to the policy by enabling, for example, server technologies detection: "policy-builder-server-technologies": { "enableServerTechnologiesDetection": true } For a list of recommended actions to mitigate this vulnerability class, please consult the referred article. Once the mitigation measures are in place, check the relevant entries in the OWASP Conformance Dashboard. Insufficient logging and monitoring (A10) K97756490: Securing against the OWASP Top 10 | Chapter 11: Insufficient logging and monitoring (A10) describes the recommended configuration to enable comprehensive logging on BIG-IP Advanced WAF. 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. After updating the policy, the OWASP Compliance Dashboard should show a full compliance: Other recommended configurations In case client connections are passing through a trusted reverse proxy that replaces the source IP address and places the client's IP address in the X-Forwarded-For HTTP header, it is recommended to enable the "Trust X-Forwarded-For" option under the WAF policy: "general": { "trustXff": true } The enforcement mode can also be controlled through the policy file, the recommendation being to set it to "transparent" mode while running the CI/CD pipeline in Dev or QA environments (or, if the policy is build outside a CI/CD pipeline, in a similar Pre-Prod environment) and configure it as "blocking" when running into a Production environment: "enforcementMode":"transparent" Conclusion This article has shown a very basic OWASP Top 10 - compliant declarative WAF policy. It is worth noting that, although this WAF policy is fully compliant to OWASP Top 10 recommendations, it contains elements that need to be customized 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 configured with additional elements. The full configuration of the declarative policy used in this example can be found on CodeShare: Example OWASP Top 10-compliant declarative WAF policyMitigating 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: 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 mitigationMitigating 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
