Avoid the continous 403 error that triggered by Azure WAFV2 CRS3.2

Question

Hello,

We noticed that our web app get a 403 error, and we also find the reason, because it triggers a rule of Azure WAFV2 CRS3.2.
And we can find the block in the Azure WAF log.
But we noticed after get the first 403 error, even we deleted the text that triggers it, or go to different page without issue, the 403 error insists and no page can be displayed.
Seems this 403 is cached by the browser, because the issue can be solved by clearing up the browser cache.

But we are wondering is there and way to avoid this behavior for specific page? Then we know that is not a attack and allow end user to get rid of this behavior?

Thanks and best regards,

Answer 1

Hello @Zhihong He , Welcome to the Microsoft Q&A forum.

As per my understanding from the question, you have an Azure WAFV2 CRS3.2 enabled for your application gateway, and for a particular request you are getting a 403 error as it blocked by WAF. If my understanding here is correct, you can follow below methodology to get rid of this issue.

WAF on Application Gateway is based on the Core Rule Set (CRS) from the Open Web Application Security Project (OWASP) to grant protection against many common attack categories, including SQL Injection, Cross Site Scripting, Local File Inclusion, etc. This is an open-source project.

The Methodology here is to.

1. Identify the rule which rule triggered this issue: If you have logging enabled for your WAF. You can identify the rule via OWASP GitHub Repo where the details.file represents the file and details.line from the Firewall Log will represent the rule section which was triggered. You can also have a look at the severity of this rule.
2. Check if it is possible to modify the application so that this rule is not hit.
3. If this rule was triggered due to false positive match. You can go through this documentation to add an exclusion list or else disable the rule itself.
4. You can also explore the option of enabling Per-URI policy for this webpage. You can associate a WAF policy with a path-based rule. If there are certain pages within a single site that require different policies, you can make changes to the WAF policy that only affect a given URI.
5. If adding exclusion rule is not possible check if you can add a custom rule instead. Just be aware that custom rule has more priority than the Managed rules above and is evaluated first.

If you are trying to add an exclusion list. The following attributes can be added to exclusion lists by name. The values of the chosen field aren't evaluated against WAF rules.

Request Headers

Request Cookies

Request attribute name (args)

It is recommended to test the Exclusion List in detection mode to validate if the requests are not blocked.
Hope this helps! Please let me know if you have any additional questions. I will be glad to continue with our discussion. Thank you!