5.3 Web Application Firewall (WAF) on Application Gateway

Web Application Firewall (WAF) on Application Gateway

Azure Web Application Firewall (WAF) on Azure Application Gateway provides centralized, cloud-native protection for web applications against common web exploits, automated vulnerabilities, and Layer 7 malicious attacks. Built directly into the WAF_v2 SKU, WAF inspects inbound HTTP and HTTPS requests before they reach backend application pools.

Without a Layer 7 firewall, web applications remain vulnerable to OWASP Top 10 exploits—including SQL Injection (SQLi), Cross-Site Scripting (XSS), Remote Code Execution (RCE), and HTTP Request Smuggling—even if backend networks are protected by Layer 4 Network Security Groups and Azure Firewall.

1. WAF Architecture, Engine & Operating Modes

Azure WAF on Application Gateway v2 uses a dedicated, high-performance rule engine that evaluates incoming requests against both Microsoft-managed intelligence rules and user-defined custom rules.

+-----------------------------------------------------------------------------+
|                      WAF INBOUND TRAFFIC EVALUATION PIPELINE                |
|                                                                             |
|   Inbound HTTP/HTTPS Request                                                |
|             |                                                               |
|             v                                                               |
|   +-------------------------------------------------------+                 |
|   | STEP 1: CUSTOM RULES EVALUATION                       |                 |
|   | - Processed in strict Priority order (e.g., 1, 5, 10) |                 |
|   | - Match Rules (IP, Geo, Headers) & Rate Limiting Rules|                 |
|   | - Terminating Actions: Allow or Block (Stop evaluation)|                |
|   +-------------------------------------------------------+                 |
|             | (If not terminated by Custom Rule)                            |
|             v                                                               |
|   +-------------------------------------------------------+                 |
|   | STEP 2: MANAGED RULES EVALUATION (OWASP CRS / MS-TI)   |                 |
|   | - OWASP Core Rule Set (CRS 3.2 / 3.1 / 3.0)           |                 |
|   | - Microsoft Threat Intelligence Collection            |                 |
|   | - Anomaly Scoring Calculation                         |                 |
|   +-------------------------------------------------------+                 |
|             |                                                               |
|             +-----------------------+-----------------------+               |
|             | (Anomaly Score < 5)   | (Anomaly Score >= 5)  |               |
|             v                       v                       v               |
|       [ Forward to Backend ]   [ PREVENTION MODE ]    [ DETECTION MODE ]    |
|       (Request Allowed)        (Return HTTP 403)      (Log Alert in Logs,   |
|                                (Block Request)         Forward to Backend)  |
+-----------------------------------------------------------------------------+

Operational Modes: Detection vs. Prevention

[!CAUTION] Production Best Practice: Never deploy a new WAF Policy directly into Prevention Mode on an active production workload without prior baseline testing. Always run the policy in Detection Mode first, analyze diagnostic logs for false positives caused by legitimate application payloads (such as JSON data containing SQL keywords), apply necessary exclusions, and then switch to Prevention Mode.

2. Managed Rule Sets: OWASP CRS & Anomaly Scoring

Azure WAF integrates pre-configured, industry-standard Managed Rule Sets maintained by Microsoft and the open-source security community.

OWASP Core Rule Sets (CRS)

• CRS 3.2 (Recommended): Modern rule set featuring enhanced performance, reduced false positive rates, expanded file upload inspection limits (up to 4 GB with large upload support), and support for Java/PHP-specific exploit detection.
• CRS 3.1 & CRS 3.0: Legacy OWASP rule sets.

Protected Attack Categories

1. SQL Injection (SQLi): Detects SQL command injections in query strings, form posts, and JSON/XML payloads.
2. Cross-Site Scripting (XSS): Blocks malicious JavaScript, VBScript, and HTML tag injection.
3. Remote Code Execution (RCE) & Command Injection: Identifies UNIX/Windows shell command executions.
4. Remote & Local File Inclusion (RFI / LFI): Blocks unauthorized local path traversals (e.g., ../../etc/passwd) and remote script executions.
5. HTTP Request Smuggling & Protocol Violations: Blocks invalid HTTP headers, multipart parsing anomalies, and content-length discrepancies.
6. Trojan & Backdoor Signatures: Blocks common web shells and backdoor probes.

Anomaly Scoring Mechanics in CRS 3.x

Unlike legacy regex firewalls that immediately block on a single rule hit, OWASP CRS 3.x utilizes an Anomaly Scoring Model:

• Individual detection rules do not block independently. Instead, each matched rule adds a severity score to the request:
  • Critical Severity: Adds 5 points (e.g., direct SQL injection pattern).
  • Error Severity: Adds 4 points.
  • Warning Severity: Adds 3 points.
  • Notice Severity: Adds 2 points.
• When all rules have executed, the total anomaly score is evaluated against the Inbound Anomaly Score Threshold (Default: 5 points). If total score $\ge 5$ and WAF is in Prevention Mode, the request is blocked (403 Forbidden).

Disabling Individual Rules

If a specific rule inside a rule group (such as Rule 942100 in the SQLi group) causes repeated false positives for a legacy internal application, administrators can disable that individual rule ID without disabling the entire SQL injection rule group.

Microsoft Threat Intelligence Collection

In addition to OWASP CRS, WAF can enable the Microsoft Threat Intelligence Collection rule set. This rule set checks incoming client source IPs in real-time against Microsoft's global cyber threat intelligence database, automatically blocking requests originating from known botnets, Tor exit nodes, and Command & Control (C2) servers.

3. Custom WAF Rules: Match Rules & Rate Limiting

Custom Rules allow administrators to define bespoke security policies tailored to unique application requirements. Custom rules are always evaluated first, before Managed Rules (CRS).

Evaluation Priority

• Custom rules are assigned a numerical priority from 1 to 100 (where 1 is the highest priority).
• Evaluation proceeds sequentially in ascending priority order (Priority 1 $\rightarrow$ Priority 2 $\rightarrow$ Priority 3).
• When a request matches a rule configured with a terminating action (Allow or Block), processing halts immediately for that request.

1. Custom Match Rules

Match rules evaluate specific attributes of an incoming request:

• Match Variables: RemoteAddr (Client IP), GeoMatch (Country/Region code), RequestMethod (GET, POST, HEAD, PUT), RequestHeaders, QueryString, RequestUri, RequestBody.
• Operators: IPMatch (CIDR ranges), GeoMatch, Equal, Contains, StartsWith, EndsWith, Regex.
• Actions: Allow (Permits request and bypasses all remaining custom and CRS rules), Block (Terminates with 403), Log (Logs without terminating).

2. Custom Rate-Limiting Rules

Rate-limiting rules prevent automated brute-force attacks, credential stuffing, and application-layer Denial of Service (DoS):

• Tracks the rate of requests matching specific criteria (e.g., RequestUri equals /api/login) from a single client IP.
• Duration Windows: Evaluated over a 1-minute or 5-minute sliding window.
• Threshold: Number of permitted requests within the window (e.g., maximum 100 requests per 1 minute).
• Action: If the threshold is exceeded, the configured action (Block or Log) is enforced against that client IP for the remainder of the window.

4. WAF Policy Hierarchy & Scoping

Azure WAF configurations are managed as standalone Azure Resource Manager (ARM) resources called WAF Policies (Microsoft.Network/ApplicationGatewayWebApplicationFirewallPolicies). A single WAF policy can be associated at three distinct hierarchical scopes:

+-----------------------------------------------------------------------------+
|                        WAF POLICY HIERARCHY SCOPES                          |
|                                                                             |
|   SCOPE 1: GLOBAL WAF POLICY                                                |
|   Associated to entire Application Gateway instance                         |
|   (Applies baseline OWASP CRS 3.2 to ALL listeners & paths)                 |
|         |                                                                   |
|         +---------------------------------------+                           |
|         | (Inherited or Overridden)             | (Overridden)              |
|         v                                       v                           |
|   SCOPE 2: PER-LISTENER WAF POLICY        SCOPE 2: PER-LISTENER WAF POLICY  |
|   Listener: public.contoso.com            Listener: api.contoso.com         |
|   (Inherits Global Policy)                (Custom Policy: Strict Rate Limit)|
|                                                 |                           |
|                                                 +---> (Overridden)          |
|                                                       v                     |
|                                           SCOPE 3: PER-URI PATH WAF POLICY  |
|                                           Path: /api/upload/*               |
|                                           (Custom Policy: 100MB Body Limit, |
|                                            Specific File Exclusions)        |
+-----------------------------------------------------------------------------+

1. Global WAF Policy: Associated directly with the Application Gateway resource. Enforces baseline protection across all listeners and URI paths unless a lower-level policy override exists.
2. Per-Listener WAF Policy: Associated with a specific Application Gateway listener (e.g., api.contoso.com). Overrides the global policy, allowing administrators to apply different CRS versions, custom rate limits, or distinct operating modes (e.g., Detection on API listener while Prevention is active globally).
3. Per-URI Path WAF Policy: Associated with a specific URL Path Map rule (e.g., /portal/upload/*). Overrides both global and listener policies to allow higher request body inspection limits, customized exclusions, or relaxed inspection for specific endpoints.

5. WAF Exclusion Lists & Sensitive Data Masking

In enterprise web environments, legitimate application parameters (such as OAuth authorization bearer tokens, XML payload strings, or password fields) frequently contain characters (like ', --, /*, <script>) that trigger false-positive SQLi or XSS rule blocks.

Exclusion Lists

Instead of completely disabling the underlying CRS detection rule across the entire application, an Exclusion List tells the WAF engine to skip inspecting a specific attribute of the request:

• Match Variable: Specifies what part of the request contains the parameter:
  • RequestHeaderNames (e.g., Header name Authorization)
  • RequestCookieNames (e.g., Cookie name session_token)
  • RequestArgNames (Query string argument name, e.g., search_filter)
  • RequestBodyPostArgNames (Form post field name)
  • RequestBodyJsonArgNames (JSON attribute key name, e.g., payload.query)
• Selector Operator: Equals, StartsWith, EndsWith, Contains.
• Selector: The exact string identifier of the key to exclude (e.g., Authorization or bearerToken).

[!NOTE] How Exclusions Function: When an exclusion is configured for RequestHeaderNames Equals Authorization, the WAF still inspects all other headers, query strings, and body fields for attacks. It only skips inspecting the value of the Authorization header, completely neutralizing false positives while maintaining comprehensive security.

Sensitive Data Masking

When WAF diagnostic logging is enabled (AGWWAFLogs), raw attack payloads are recorded in Azure Log Analytics for forensic analysis. However, compliance standards (PCI-DSS, HIPAA, GDPR) prohibit storing plain-text passwords, credit card numbers, or personally identifiable information (PII) in log repositories.

• Sensitive Data Masking Rules allow administrators to define field selectors (e.g., RequestBodyJsonArgNames Equals password or RequestHeaderNames Equals X-Credit-Card).
• The WAF engine replaces the logged value of these fields with masked characters (*****) before writing logs to Azure Monitor, ensuring regulatory compliance without impeding security operations.