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 policy

Updated Jun 08, 2022
Version 2.0
BIG-IP
devops
owasp
OWASP-App-Security
Verified Designs
waf
No CommentsBe the first to comment