MicrosoftHi, could you clarify how to apply the Application Gateway WAF examples in this article?
There appears to be a gap between the published configuration and the Azure Portal:
Entering Content-Type as the Post args selector would select a form parameter named Content-Type; it would not refer to the HTTP header, so that does not resolve the deployment gap.
Could you provide a validated deployment procedure for all three Application Gateway rules, specify the required ruleset/engine versions, and include harmless test requests with the expected WAF log matches?
The missing selector instructions and field-name inspection details make it difficult to establish whether the deployed rules provide the intended coverage.
Microsoft1. Azure Portal UI making the selector mandatory, looks like a portal only limitation. The CLI/API supports PostArgs without a selector, match against ALL post parameter values. Here is an example to create a rule without selector -
# CLI example - no selector
az network application-gateway waf-policy custom-rule create \
--policy-name <policy> --resource-group <rg> \
--name BlockPhpSessionUploadProgress --priority 90 --action Block \
--match-condition variable=PostArgs operator=Contains values=php_session_upload_progress transforms=Lowercase
Or useARM template / Bicep / REST API.
2. PostArgs, with a selector (e.g. PostArgs:password ), only matches the value of the named parameter. PostArgs, without a selector, iterates all parsed form parameters and matches against both names and values. Hence, to match both name and value of every field in URL-encoded, multipart, and JSON bodies, including the field names of file uploads. It does not check the contents of uploaded files. So, PHP_SESSION_UPLOAD_PROGRESS used as a field name is detected, and so is 20-level bracket nesting in multipart field names. One point noteworthy is the same text appearing in a field's value will also match.
You would need WAF_v2 SKU with CRS 3.2, DRS 2.1 or DRS 2.2, which run on the next-generation Azure WAF engine. Turn on request body checking. Either turn on request body enforcement or set the inspection limit higher than your largest non-file form data. Otherwise,, the upload-progress field can be pushed past the inspected portion of the request.
On a related note, our test results show adding request body enforcement is also an effective mitigation against these types of attack.
