Search

Azure Web Application Firewall provides a comprehensive solution for protecting web applications from various types of application attacks, ensuring high availability and optimal performance. It is critical to configure WAF in such a way as to reduce the likelihood of false positives while still providing sufficient protection against actual threats.

False positives occur when a Web Application Firewall ( WAF ) erroneously detects legitimate web traffic as malicious and subsequently denies access. For instance, an HTTP request that poses no threat may trigger WAF to classify it as an SQL injection attack due to how characters are passed through the request body, thereby causing the request to be rejected and denying access to the user.

The first step in reducing false positives is to understand the logs and how to configure and tune WAF rulesets (Managed ruleset, Bot Ruleset and Custom rules).

Prerequisite read:

Tuning Web Application Firewall (WAF) for Azure Front Door | Microsoft Learn

Troubleshoot - Azure Web Application Firewall | Microsoft Learn

Most recent CRS (3.2 for Application Gateway)

When requests are incorrectly matched and blocked by WAF, there are actions that may be taken upon reviewing the logs based on the application type, request origin, bot activity among others. The following are suggestions that may be helpful in reducing the false positives in your WAF environment. Test these suggestions in Detection mode and confirm they work for your environment.

SharePoint

If you use SharePoint to host internal endpoints such as knowledge base or blogs, then there are some rules that might be worth reviewing to reduce the chances of false positives.

The Microsoft SharePoint Search REST API for example can be used to model your API design. A good example is the CDN support- If your search results contain images that are served from the CDN, then the URL for the image will be the CDN URL that is returned in the results and not the asset library location.

This API development guideline provides insight that makes it easy to identify requests bound for SharePoint workloads. They however require special characters that trigger SQLi rules.

If there are no databases to modify in the back end, then for the following attribute names SPHostUrl and SPSiteUrl , create the exclusion for the request path.

You can then carefully disable the following rules.

SQL Injection Attack: Common DB Names, Libinjection sources, Conditions and Char injection etc.

If there is no database configured in backend nodes, then these may be carefully reviewed and disabled

Possible Remote File Inclusion (RFI) Attack: Common RFI Vulnerable Parameter Name used w/URL Payload

This is triggered with ftps connections and may be disabled/excluded for off-domain reference link

Application insight

If your Azure endpoints have not been written in a particular language, for example Php, it is worth considering that scanner tools with requests from other languages e.g. “.php” applications can be blocked. This same logic also applies to other failed responses due to unavailability of the requested endpoint. In this scenario, this may be achieved by creating a custom rule that blocks .php requests. You can use Azure Application Insight to detect non-valid requests. Application insight provides live metrics, availability, usage, and smart detection for your application. In this example, I have an application written in ASP.Net that I have deployed from Azure templates .  You can go under Investigate Performance to see the visualization of responses. Then go to Failures to select any of the operation name items to see the response code and request URL. In my example, response code 404 with .php URL provides good information about an example of source traffic that I may want to completely block using Azure WAF. App Insight in this way can give visibility into requests from web crawlers and request for potential HTTP parameter pollution attack.

If Application insight is enabled for your app, Go to View Application Insight data .

Go to Failures and review all errors with status code greater than > 300. In my example, I have mostly error 404.

By clicking on the 404 error, the URL with the error is revealed. In this case, the two causes of the errors are a PHP vulnerability used via HTTP Post request that allows attackers to execute arbitrary PHP code beginning with a "<?php " substring and a Scanner for Outlook Web Access (OWA)/Microsoft Exchange Control Panel ECP, a connection attempt to an “outlook login page”. The two URLs are https://dotnetappsite.azurewebsites.net/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php and https://dotnetappsite.azurewebsites.net/owa/auth/logon.aspx

Since this application was not written in php and there is no login page, a custom rule in WAF may be used to deny these URIs from getting to the application using Azure WAF.

If you do not have Application insight installed, you can also use the Azure WAF Monitor Workbook and Azure Storage Explorer to view error statistics in your azure environment. Look for errors greater than 399 e.g.

400 - server unable to process response/ or Rule Based Routing not finding the page

401 - authentication failed

402 - Payment failed/required

403 - Probably blocked due to access/rule e.g., from firewall. Forbidden

404 - Page not found on Server / or Rule Based Routing not finding the page

Make sure to test that resources are rightly available upon setting up the custom rules.

3. WordPress Applications

WordPress applications are common among web app workloads in several app delivery platforms.

There are some steps to reduce common false positive errors in your WAF activity and this starts with understanding why some rules are triggered. One of such instances is when listing child pages in WordPress, the content of a POST body parameter “ wp_post ” causes rule 941320 to get triggered . This rule inspects HTML tag and would trigger a match against XSS attack due to HTML tags.

# CRS Rule Exclusion: 941320 - Possible XSS Attack Detected - HTML Tag Handler

By creating an exclusion for the query string “wp_post” at a rule level against rule 941320, you can exclude this event from triggering the WAF.

4. Pattern match review with Regular Expression

SecRule 942120 : This OWASP signature ID uses a set of regex pattern matching. For a particular rule ID that has been triggered, you can look through the OWASP ModSecurity glossary to see the parameter combination that matched the regex expression. For example, SQLi rule 942120 looks for combinations such as " in+not ", “ xor ”, “ is+null ” or “ in+null ” etc. in a request string. Other matches in this pattern include:

in: matches the literal string "in".

[+\s]*: matches zero or more whitespace or plus characters.

\(: matches an opening parenthesis.

[\s\d\"]+: matches one or more whitespace, digit, or double-quote characters.

[^()]*: matches zero or more characters that are not parentheses.

\) : matches a closing parenthesis.

The likelihood of the occurrence of this string might be low but not uncommon in Cyrillic texts. This rule is also triggered by the exploit CVE-2018-2380 so it’s worth troubleshooting. By creating an exclusion for this string in WAF or using a custom rule to allow the request URI with this string, false positives can be reduced.

SecRule ARGS_NAMES|ARGS|XML:/* "@rx (?i:(?:(?:^|\W)in[+\s]*\([\s\d\"]+[^()]*\)|\b(?:r(?:egexp|like)|isnull|xor)\b|<(?:>(?:\s+binary)?|=>?|<)|r(?:egexp|like)\s+binary|not\s+between\s+0\s+and|(?:like|is)\s+null|>[=>]|\|\||!=|&&))" \
    "id:942120,\
    phase:2,\
    block,\
    capture,\
    t:none,t:utf8toUnicode,t:urlDecodeUni,\
    msg:'SQL Injection Attack: SQL Operator Detected',\

Log analytics provide some insight into the match value for the trigger.

Here is a sample text to check the pattern match using regex101.com to find the combinations triggering a match for the rule 942120. The match is also revealed in the details_data_s

b. SecRule 942430: This is another SQLi rule that utilizes pattern matching in the request. This rule is triggered by the cumulative occurrence of certain characters or symbols up to 12 times . You can use regex101.com to review which of the characters occurred more than 12 times in the request body/ details_data_s. This type of error is common in some SSO application due to the use of SAML (Security Assertion Markup Language) authentication with large character set for Single Sign On

A URL with parameter value of these characters http://20.125.136.95/Home/About?param_name=AA%22\%22\;++'+(*<@

is likely to trigger this rule due to the occurrence of these characters up to 12 times.

SecRule ARGS_NAMES|ARGS|XML:/* "@rx ((?:[~!@#\$%\^&\*\(\)\-\+=\{\}\[\]\|:;\"'´’‘`<>][^~!@#\$%\^&\*\(\)\-\+=\{\}\[\]\|:;\"'´’‘`<>]*?){12})" \
    "id:942430,\
    phase:2,\
    block,\
    capture,\
    t:none,t:urlDecodeUni,\
    msg:'Restricted SQL Character Anomaly Detection (args): # of special characters exceeded (12)',\
    logdata:'Matched Data: %{TX.1} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',\
The logs usually provide the match message in details_data_s field. The match message can be verified using regex101 as in (a.) above. An exclusion to address the matching pattern may then be used to permit the traffic based on the matched value. A custom rule that uses the  request_url may also be used to bypass the inspection but this will allow all traffic in this path to bypass inspection.
The exclusion above makes it possible to let this request be bypassed by the trigger.
Finally, If you see rule ID 949110 during the process of tuning your WAF, this indicates that the request was blocked by the anomaly scoring process. The 
The key idea in fine tuning your environment once you identify false positives is to find a way to reduce the anomaly score that led to the block. This is evident in the logs by looking at the matches that eventually led to the block and working to reduce the cumulative score.
Resources:
Tuning Web Application Firewall (WAF) for Azure Front Door | Microsoft Learn
Troubleshoot - Azure Web Application Firewall | Microsoft Learn
Best practices for Web Application Firewall on Azure Application Gateway | Microsoft Learn