Alex D'Antico Tech

In a recent scenario, I encountered an issue with my Azure Application Gateway WAF policy that highlighted the importance of understanding all parameters involved in configuration commands via the Azure CLI. Specifically, I was toggling my WAF policy between Detection and Prevention mode using Azure CLI commands but overlooked a critical parameter that led to unintended results.

The Scenario

An App Gateway WAF has two modes:

1. Detection mode: Monitors and logs all threat alerts. The web application firewall doesn’t block incoming requests when operating in Detection mode.
2. Prevention mode: Blocks intrusions and attacks that the rules detect. The attacker receives a “403 unauthorized access” exception, and the connection is closed.

Obviously, you want your WAF to be in Prevention mode most of the time, but occasionally for maintenance, troubleshooting, or to allow non-devs to toggle the mode of the WAF, I designed a pipeline that enables this without having to update any IaC or commit to the main branch. A common scenario for toggling the WAF to Detection mode is during load testing or penetration testing, where you don’t want the WAF to impact the results of these tests. The commands I used were:

# Switch to Detection mode
az network application-gateway waf-policy policy-setting update --policy-name <my-wav-polocy> --resource-group <my-resource-group> --mode Detection

# Switch to Prevention mode
az network application-gateway waf-policy policy-setting update --policy-name <my-wav-polocy> --resource-group <my-resource-group> --mode Prevention

The Overlooked Parameter

What I didn’t realise is that there is a parameter --request-body-check that defaults to false when it is not explicitly set. This parameter controls whether the WAF inspects the body of HTTP requests. By not explicitly setting this parameter, I had inadvertently disabled all request body inspection when switching back to Prevention mode, which could allow potentially malicious traffic to pass through that should have been blocked. Obviously, this is not ideal…

The Solution

Luckily, this happened in our Test environment, so no malicious actors were able to exploit anything in our system. Our proper monitoring and alerting systems allowed us to notice the strange behavior of the WAF in the Test environment compared to our other environments (i.e., it wasn’t blocking anything!). I would highly recommend not running these az commands in your production environment.

This experience underscored the importance of understanding all parameters and their defaults when configuring security policies. Ensure you read and understand the consequences of all commands before running them.

This also underscored to me the completely whack --request-body-check parameter, which defaults to false! This same behavior does not occur when switching the WAF mode in the portal or via IaC, so I therefore only take partial blame for this ordeal… C’mon Microsoft…