Lab 05 - Switch to Prevention Mode and Validate Protection¶

cd C:\Users\lramoscostah\Downloads\scripts

   .\generate-traffic.ps1 -TargetUrl "https://<appgw-public-ip>" -AttackType SQLi
   ```

3. Observe the output. You should now see **403 Forbidden** responses instead of 200 OK.

### 2.2 Run Cross-Site Scripting (XSS) Attacks

1. Execute XSS attacks:

   ```powershell
   .\generate-traffic.ps1 -TargetUrl "https://<appgw-public-ip>" -AttackType XSS
   ```

2. Again, observe that responses return **403 Forbidden**.

### 2.3 Run Path Traversal Attacks

1. Execute path traversal attacks:

   ```powershell
   .\generate-traffic.ps1 -TargetUrl "https://<appgw-public-ip>" -AttackType PathTraversal
   ```

### 2.4 Run Command Injection Attacks

1. Execute command injection attacks:

   ```powershell
   .\generate-traffic.ps1 -TargetUrl "https://<appgw-public-ip>" -AttackType CommandInjection
   ```

### 2.5 Run All Attacks

1. Alternatively, run all attack types at once:

   ```powershell
   .\generate-traffic.ps1 -TargetUrl "https://<appgw-public-ip>" -AttackType All
   ```

> **📝 Note:** Keep the terminal output visible. You will compare the HTTP response codes (403 vs 200) in the next section.

---

## Section 3: Verify Blocking

After running the attacks, verify that the WAF is actively blocking malicious requests.

### 3.1 Check HTTP Response Codes

1. In the PowerShell output from the attack scripts, look for the HTTP status codes:

   ```
   [BLOCKED] 403 Forbidden - SQL Injection attempt: ?id=1' OR '1'='1
   [BLOCKED] 403 Forbidden - XSS attempt: ?input=<script>alert('xss')</script>
   [BLOCKED] 403 Forbidden - Path Traversal attempt: /../../etc/passwd
   ```

2. Verify that **all attack requests** return **403 Forbidden**.

### 3.2 Manual Verification with curl

1. Test a SQL injection attempt manually:

   ```powershell
   # SQL Injection - should return 403
   Invoke-WebRequest -Uri "https://<appgw-public-ip>/?id=1' OR '1'='1" `
     -SkipCertificateCheck -Method GET 2>&1 | Select-Object StatusCode, StatusDescription
   ```

2. Test an XSS attempt manually:

   ```powershell
   # XSS - should return 403
   Invoke-WebRequest -Uri "https://<appgw-public-ip>/?input=<script>alert('xss')</script>" `
     -SkipCertificateCheck -Method GET 2>&1 | Select-Object StatusCode, StatusDescription
   ```

3. You should receive a **403 Forbidden** response with a generic error page indicating the request was blocked.

### 3.3 Verify via Application Gateway Metrics

1. In the Azure Portal, navigate to your **Application Gateway** resource.

2. Click **Metrics** in the left-hand menu.

3. Add the metric **Web Application Firewall Total Rule Distribution** with the filter:
   - **Action** = `Blocked`

4. Set the time range to the **Last 30 minutes**.

5. You should see a spike in blocked requests corresponding to your attack traffic.

---

## Section 4: Verify Legitimate Traffic Still Works

It is critical that Prevention mode does not block legitimate application traffic.

### 4.1 Test Normal HTTP Requests

1. Send a standard request to the application root:

   ```powershell
   $response = Invoke-WebRequest -Uri "https://<appgw-public-ip>/" `
     -SkipCertificateCheck -Method GET
   Write-Host "Status: $($response.StatusCode) $($response.StatusDescription)"
   ```

   Expected: **200 OK**

2. Test a request with normal query parameters:

   ```powershell
   $response = Invoke-WebRequest -Uri "https://<appgw-public-ip>/api/products?category=electronics&page=1" `
     -SkipCertificateCheck -Method GET
   Write-Host "Status: $($response.StatusCode) $($response.StatusDescription)"
   ```

   Expected: **200 OK**

3. Test a POST request with standard form data:

   ```powershell
   $body = @{
       username = "john.doe"
       email    = "john@example.com"
   }
   $response = Invoke-WebRequest -Uri "https://<appgw-public-ip>/api/users" `
     -SkipCertificateCheck -Method POST -Body $body
   Write-Host "Status: $($response.StatusCode) $($response.StatusDescription)"
   ```

   Expected: **200 OK** or **201 Created**

### 4.2 Generate Legitimate Traffic Batch

1. Use the traffic generation script with legitimate traffic:

   ```powershell
   .\generate-traffic.ps1 -TargetUrl "https://<appgw-public-ip>" -AttackType None -Count 50
   ```

2. Verify all responses return **200 OK**.

---

## Section 5: Verify Exclusions Work

Exclusions configured in Lab 04 should continue to allow specific parameters through even in Prevention mode.

### 5.1 Test Excluded Parameters

1. If you previously created an exclusion for a parameter (e.g., `searchQuery`), test it now:

   ```powershell
   # This request contains a pattern that normally triggers WAF rules
   # but should be allowed through because of the exclusion
   $response = Invoke-WebRequest `
     -Uri "https://<appgw-public-ip>/search?searchQuery=select * from products" `
     -SkipCertificateCheck -Method GET
   Write-Host "Status: $($response.StatusCode) $($response.StatusDescription)"
   ```

   Expected: **200 OK** (because the `searchQuery` parameter is excluded from WAF inspection)

2. Verify that the same pattern in a **non-excluded** parameter is still blocked:

   ```powershell
   # Same pattern but in a non-excluded parameter - should be blocked
   try {
       $response = Invoke-WebRequest `
         -Uri "https://<appgw-public-ip>/search?otherParam=select * from products" `
         -SkipCertificateCheck -Method GET -ErrorAction Stop
       Write-Host "Status: $($response.StatusCode)"
   } catch {
       Write-Host "Status: $($_.Exception.Response.StatusCode.Value__) - Blocked as expected"
   }
   ```

   Expected: **403 Forbidden**

### 5.2 Review Exclusions in Portal

1. Navigate to **WAF Policy** → **Managed rules** → **Exclusions**.

2. Verify your exclusions are still listed and active.

3. Confirm that the exclusion scope (Global, Per-rule, or Per-rule-group) is correct.

---

## Section 6: Analyze Prevention Mode Logs

### 6.1 Query Blocked Events in Log Analytics

1. Navigate to your **Log Analytics workspace** in the Azure Portal.

2. Click **Logs** in the left-hand menu.

3. Run the following KQL query to see blocked requests:

   ```kql
   AzureDiagnostics
   | where ResourceType == "APPLICATIONGATEWAYS"
   | where Category == "ApplicationGatewayFirewallLog"
   | where action_s == "Blocked"
   | where TimeGenerated > ago(1h)
   | project
       TimeGenerated,
       clientIp_s,
       requestUri_s,
       ruleId_s,
       ruleSetType_s,
       ruleSetVersion_s,
       ruleGroup_s,
       message_s,
       action_s,
       details_message_s,
       details_data_s
   | order by TimeGenerated desc
   | take 50
   ```

4. Review the results. You should see:
   - **action_s** = `Blocked` for all attack requests
   - The **ruleId_s** identifies which WAF rule triggered the block
   - The **message_s** provides a description of the detected threat

### 6.2 Summarize Blocked Requests by Rule

```kql
AzureDiagnostics
| where ResourceType == "APPLICATIONGATEWAYS"
| where Category == "ApplicationGatewayFirewallLog"
| where action_s == "Blocked"
| where TimeGenerated > ago(1h)
| summarize
    BlockedCount = count(),
    UniqueIPs = dcount(clientIp_s),
    SampleUri = any(requestUri_s)
    by ruleId_s, ruleGroup_s, message_s
| order by BlockedCount desc

Invoke-WebRequest -Uri "https://<appgw-public-ip>/?id=1' OR '1'='1" `
  -SkipCertificateCheck -Method GET 2>&1