Navigating Azure WAF Exclusions

This post has been republished via RSS; it originally appeared at: Microsoft Tech Community - Latest Blogs - .

Introduction

Exclusions in Azure WAF (Web Application Firewall) are a critical feature that allows administrators to fine-tune security rules by specifying elements that should not be evaluated by WAF rules. This capability is essential for reducing false positives and ensuring that legitimate traffic flows unimpeded. Exclusions are designed to fine-tune the WAF’s sensitivity, allowing legitimate traffic to pass through while maintaining robust security measures. They are particularly useful in scenarios where certain request attributes, such as specific cookie values or query strings, are known to be safe but might trigger WAF rules due to their content or structure.

Azure WAF Exclusions: A Closer Look

Azure WAF exclusions can be applied to a rule, set of rules, rule group, or globally for the entire ruleset. This flexibility is crucial for meeting application-specific requirements and reducing false positives. For instance, exclusions introduced with CRS 3.2 on regional WAF with Application Gateway now allow attribute exclusions definitions by name or value of header, cookies, and arguments.

Attributes for WAF exclusions

• Attributes that can be excluded include:
• Request headers
• Request cookies
• Query strings
• Post args
• JSON entity (only for AFD WAF)
• Operators for exclusions include:
• Equals: For exact matches.
• Starts with: Matches fields starting with a specific selector value.
• Ends with: Matches fields ending with a specified selector value.
• Contains: Matches fields containing a specific selector value.
• Equals any: Matches all request fields (useful when exact values are unknown).

Note: The “Equals Any” condition automatically converts any value you enter in the selector field to an asterisk (*) by the backend when creating an exclusion. This feature is especially valuable when handling unknown or random values.

• Exclusions can be applied on:
• Rule
• Rule set
• Rule group
• Global

Azure Front Door WAF: Exclusion Example

Azure Front Door WAF allows for exclusions to be set at a detailed level, targeting the values of match variables like request headers, cookies, and query strings. This granularity ensures that only the necessary parts of a request are excluded from rule evaluation, reducing the likelihood of false positives without significantly impacting the overall security posture.

When configuring Azure Web Application Firewall (WAF) to inspect JSON request bodies, it’s crucial to understand how to handle legitimate requests that might otherwise be flagged as potential threats. For instance, consider the following JSON request body:

JSON Example

{

  "posts": [

    {

      "eid": 1,

      "comment": ""

    },

    {

      "eid": 2,

      "comment": "\"1=1\""

    }

  ]

}

In this example, the "1=1" in the comment field could be mistaken by the WAF as a SQL injection attempt. However, if this pattern is a normal part of your application’s operation, you can create an exclusion to prevent false positives. By setting an exclusion with a match variable of Request body JSON args name, an operator of Equals, and a selector of posts.comment, you instruct the WAF to overlook the “comment” property when scanning for threats. To refine the exclusion and make it more specific, we have applied it solely to the ‘SQLI’ rule group and the ‘942150 SQL Injection Attack’ rule. This ensures that only this particular selector is exempt from inspection by this rule, while all other rules will continue to inspect it for any threats.

Note: JSON request bodies inspection For Azure Front Door WAF is available from DRS 2.0 or newer.

Application Gateway WAF: Exclusion Example

For WAF on Application gateway we will use a different JSON example:

JSON Example

{

    "properties": {

        "credentials": {

            "emai.l=l": "admin",

            "password": "test"

        }

    }

}

In the previous example, we examined the value of the selector. However, in this case, our focus is on excluding the selector key itself, rather than excluding the value within the key. Above in the JSON example you can see “properties.credentials.emai.l=l” and  This specific key contains “l=l”, which could potentially trigger an SQL injection attack rule. To exclude this specific selector, we’ve created an exclusion rule matching the variable “Request Arg Keys” with the value “properties.credentials.emai.l=l”. This exclusion prevents further false positives.

This feature is available in Application Gateway WAF and only in CRS 3.2 or newer and Bot Manager 1.0 or newer. By excluding the key/selector itself, we significantly improve the tuning of WAF false positives. For more WAF Exclusion examples see here Web application firewall exclusion lists in Azure Application Gateway - Azure portal | Microsoft Learn

Furthermore, within Application Gateway WAF, you have the flexibility to selectively apply this exclusion to specific rules. In our scenario, we’ve opted to apply it to Rule 942130: SQL Injection Attack: SQL Tautology. This means that we’re excluding this particular key only for this specific rule, while still ensuring that the rest of the JSON is thoroughly inspected by the remaining ruleset

Note: Request attributes by names function similarly to request attributes by values and are included for backward compatibility with CRS 3.1 and earlier versions. However, we it’s recommended using request attributes by values instead of attributes by names. For instance, opt for RequestHeaderValues rather than RequestHeaderNames

This approach ensures that legitimate traffic is not inadvertently blocked, maintaining the flow of your application while still protecting against actual security risks. It’s a delicate balance between security and functionality, and exclusions are a powerful tool in the WAF’s arsenal to achieve this balance. Always verify the legitimacy of such patterns before creating exclusions to maintain the security posture of your application.

Match variable mapping.

When setting up exclusions, it can be challenging to map the Match variables you observe in your logs to the corresponding configuration on your Web Application Firewall (WAF). By referring to this table, you can streamline the exclusion process and ensure that your WAF is accurately tuned to your traffic.

Azure Application Gateway

Azure Front Door WAF

Best Practices for Implementing Exclusions

When implementing exclusions, it’s crucial to follow a structured approach:

1. Document Current Settings: Before making any changes, document all existing WAF settings, including rules and exclusions.
2. Test in Staging: Apply and test exclusions in a non-production environment to ensure they work as intended without introducing new risks.
3. Apply to Production: Once verified, apply the tested exclusions to the production environment, monitoring closely for any unexpected behavior.

Conclusion

Exclusions in Azure WAF, whether for Azure Front Door or Application Gateway, offer a nuanced approach to web application security. By understanding and utilizing these features, administrators can ensure that security measures are effective without disrupting legitimate user activity. As Azure WAF continues to evolve, the ability to fine-tune security through exclusions will remain a cornerstone of its effectiveness.

Resources

• Web application firewall exclusion lists in Azure Application Gateway - Azure portal | Microsoft Learn
• Web application firewall exclusion lists in Azure Front Door | Microsoft Learn
• Examine WAF logs using Azure Log Analytics - Azure Application Gateway | Microsoft Learn
• Best practices for Azure Web Application Firewall (WAF) on Azure Application Gateway | Microsoft Learn