How to fix Failed to parse request body, Multipart request body failed strict validation

@Sharanaiyya Swami

There are two Azure WAFs, one for App Gateway and AFD.

Looking at the logs, it appears you are using App Gateway WAF with OWASP 3.2.

You have to tune your WAF to your environment and use case.

You can

1. Disable the Rule : See Tuning of Managed rule sets
2. or Create Exclusions : https://video2.skills-academy.com/en-us/azure/web-application-firewall/ag/application-gateway-waf-configuration?tabs=portal
3. or Create a custom rule : Custom rules for Web Application Firewall

to overcome this.

Depending on your application and traffic, you have to configure the above.

Cheers,

Kapil

Hello Kapil,

The answer is too generic from Microsoft, though we refer the provided doc we couldn't figure out how to make custom rule or exclusion for this kind of scenario, Below is the error.

Kondlyada, Navaneeth Reddy ,

The CRS Rules are not defined by Microsoft.

The App gateway WAF Engine just implements them.

• Without looking at the actual request (both Headers and Body) , we will not be able to comment on why the request is considered malicious/blocked.
• Also, different applications would expect different kind of traffic and based on your application, you should check if the request is actually a false-positive or not.

For Rule definition, please refer : https://github.com/SpiderLabs/owasp-modsecurity-crs/tree/v3.2/master/rules

Cheers,

Kapil

Hello @Sharanaiyya Swami & @Kondlyada, Navaneeth Reddy ,

The OWASP rulesets are designed to be strict out of the box, and to be tuned to suit the specific needs of the application or organization using WAF. It's entirely normal, and expected in many cases, to create exclusions, custom rules, and even disable rules that may be causing issues or false positives.

Looking at the logs & screenshots you shared, below are my inputs:

• Both these rules you are hitting are actually Parse checking rules.
• Rule 200002 is a block due to parsing the request body. And is normally how to the client sends the request.
• Rule 200003 is verifying that the body is ok. The format shouldn't be malformed.
• The WAF is looking at the stream of the file and trying to determine if the formatting of the multipart request is valid. If it thinks it's not, the body check fails, and the rest of the request can't be scanned.
• The 200002/200003 family of rules that are available in OWASP 3.2 are very difficult to work around because they are looking at the formatting of the request. How the request is formatted is almost impossible to predict because the streaming of a file that get encoded into a bunch of random characters, and if those characters break the typical formatting boundaries of a multipart request these rules will trigger
• Since we cannot predict how a file will get encoded during a stream, it's almost impossible to "fix" from a code/request level.
• This is known behavior with these rules and if you have body inspection ON, they can potentially cause unusual behavior.
• So, we generally advise customers to disable the rule ID.

Refer: https://video2.skills-academy.com/en-us/azure/web-application-firewall/ag/application-gateway-waf-configuration?tabs=portal#identify-request-attributes-to-exclude

As you have not shared the complete WAF log JSON, I'm not sure on which specific URI or request header, this error is getting triggered.

If these errors are getting triggered for a specific URI, you can create a custom rule with match variable "RequestUri", as exclusion lists do not support request URI or hostname as a request attribute to exclude.

https://video2.skills-academy.com/en-us/azure/web-application-firewall/ag/custom-waf-rules-overview#match-variable-required

Additional references for you:

https://video2.skills-academy.com/en-us/answers/questions/1195720/multipart-request-body-failed-strict-validation-an

https://stackoverflow.com/questions/72322174/waf-200003-multipart-request-body-strict-validation

https://video2.skills-academy.com/en-us/answers/questions/1092665/access-denied-with-code-403-(phase-2)-match-of-eq

Regards,

Gita