WAF (v2) Managed Exclusion Rule difficulty with a particular request.

Question

Hi experts..

I have a particularly troublesome request being blocked and am seemingly unable create a suitable managed exclusion rule, although it appears that it should be possible.

We have an asp.net (web forms) application that uses SSRS ReportViewer to embed reports into pages. One of these reports includes drill functionality, which when actioned creates the problem request.

Specifically, when a value in the parent report is clicked to perform a drill, the below POST request is made (I have excluded the host path from here):
Reserved.ReportViewerWebControl.axd?OpType=SessionKeepAlive&ControlID=3030b370e85c4323855042a247d4cb03

In addition to the above query string parameters, the browser tools show that the request payloads some form data that contains \r\n which matches OWASP 921150 "http header injection attack via payload (CR/LF detected)". The form data is not a readable/consistent string so appears to be of no use in terms creating a managed rule exclusion.

I have attempted to create a Managed Rule Exclusion based on all possible permutations of request arg names / keys / values for OpType / SessionKeepAlive / ControlID using contains / equals / contains ReportViewer etc etc (these were all tried one at a time and tested individually) but nothing results in the request being allowed. I am using case sensitive values for safety.

I am at a loss as to how to proceed and would appreciate any advice!

Thank you.

Answer 1

Hello @Richard ,

I understand that your WAF (v2) Managed rules are blocking a particular request, and you would like to know how to fix this.

We worked offline to understand the request and the respective WAF log triggering the block and below is the analysis:

From the browser trace, fiddler and WAF logs, we found that the block was triggering for the request body, but the request body contained random form data without any consistent key/name.

Till now, you were trying to configure exclusions on the Query String data (Request Arg Names / Keys / Values) using consistent values such as OpType, SessionKeepAlive, ControlID etc. but the form data was evaluated in isolation of the query string as the trigger was due to the request body and not the query string.

As mentioned in the Azure WAF document, WAF exclusion lists allow you to omit certain request attributes from a WAF evaluation, but the rest of the request is evaluated as normal:

Difference between Exclusion lists and Custom Rules:

Exclusions:

You define an exclusion based on 1st parameter in one URL

• Only the specific URL parameter is excluded
• If the URL has 2 parameters, the 2nd parameter is NOT excluded
• Entire request is still processed - validation continues

CustomRule:

You define a rule based on URL

• Entire request is allowed/blocked based on the matched rule - validation ends here
• No more rules processing

So, even when you use an exclusion with matchVariable such as Request Arg Names / Keys / Values using consistent values such as OpType, SessionKeepAlive, ControlID etc, the form data with random value is not considered as the form data is part of the request body and not query string and is not related to the parameter key/name you configured. And on top of that, the request body only has the random form data, there is no consistent key/name that can be used to create an exclusion for the request body.

Therefore, the only possibilities here are:

• Create a custom rule.
• Disable the managed rule triggering the block.

Since the query string has consistent parameters such as OpType and ControlID, you can create a custom rule to allow such requests to bypass the WAF.

Refer: https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/custom-waf-rules-overview

But you mentioned that you try to avoid custom rules as much as possible and think the better option will be to disable the specific rule.

Kindly let us know if the above helps or you need further assistance on this issue.

---

Please "Accept the answer" if the information helped you. This will help us and others in the community as well.