如何解决Azure WAF针对密码字段的误判拦截问题（Azure Front Door环境）

Great question—this is a common pain point when balancing WAF security with legitimate user input needs. Let’s break down actionable solutions that keep your login page protected from real SQL injection attempts while letting valid passwords through:

1. Tune the SQLI Rule with Targeted Exceptions #

Instead of excluding the entire password field, create a rule-specific exception that only applies to your login page’s password input. This way, you keep the rule active for all other parts of your site while bypassing it for valid password submissions:

• In the Azure Portal, navigate to your Front Door WAF policy.
• Under Managed rules, locate Microsoft_DefaultRuleSet_1.0 and find the 1.0-SQLI-942100 rule.
• Add an exception for this rule with these conditions:
  • Match type: Request URI equals your login page path (e.g., /login)
  • Match type: Request method equals POST
  • Match type: Form data (or JSON body if using API-based login) where the field name is password and the value matches your allowed password pattern (e.g., ^[A-Za-z0-9\-()_]+$ for your example format)
• Set the exception action to "Allow" to let valid passwords bypass this specific rule.

2. Upgrade to a Newer Managed Rule Set #

The 1.0 rule set is outdated—Microsoft’s newer rule sets (like Microsoft_DefaultRuleSet_2.1 or 3.0) include improved context-aware logic that reduces false positives for SQL injection detection. These updates better distinguish between benign special characters in password fields and actual injection patterns.

• Test the newer rule set in Detection mode first to verify it doesn’t introduce new issues, then switch to Prevention mode once you’re confident in its performance.

3. Create a Custom Allow Rule with Higher Priority #

If tuning the existing rule isn’t sufficient, build a custom WAF rule that runs before the managed rule set to explicitly allow valid password submissions:

• In your WAF policy, go to Custom rules and add a new rule.
• Set the rule priority higher than the managed rule set (lower number = higher priority) so it executes first.
• Configure the rule conditions:
  • Request URI matches your login path
  • Request method is POST
  • Form data/JSON body field password matches your allowed password regex pattern
• Set the rule action to "Allow"—this will let valid passwords through before the SQLI rule can flag them.

4. Adjust Rule Sensitivity (If Supported) #

Some managed rules let you tweak sensitivity levels to reduce false positives. For 1.0-SQLI-942100, check if you can lower its sensitivity from "High" to "Medium" or "Low". This reduces the likelihood of flagging benign special characters while still catching genuine injection attempts.

• Note: Not all rules support sensitivity adjustments, but it’s worth checking in the Azure Portal’s rule configuration panel.

Bonus: Refine Password Character Allowlist (If You Choose This Path) #

If you decide to restrict special characters, you don’t need to exclude all "risky" ones—define a clear allowlist that balances complexity and WAF compatibility. For your example password 12-(Maria)_1002, explicitly allow these characters:

• Alphanumeric characters (A-Z, a-z, 0-9)
• Hyphens (-)
• Parentheses (())
• Underscores (_)
  Enforce this via client-side validation (to give users immediate feedback) and server-side validation (as a security fallback).

内容的提问来源于stack exchange，提问作者Mr M