As designed by Microsoft, the Azure Web Application Firewall with the CRS 3.2 engine will block requests that form part of the OAuth flow used by the Azure App Service provided built-in authentication and authorization.
This repository provides a bicep script to add exclusions to allow problematic rules for these requests.
Assuming $GROUP and $POLICY_NAME envvars for your deployment, apply these rules with:
az deployment group create --resource-group $GROUP --template-file policy.bicep \
--parameters policyName=$POLICY_NAME
Note this will override existing settings in the policy, not add to them. Other rules are likely to need exclusions for your application to function reliably.
Many of the rules used by the firewall attempt to detect broad classes of potentially dangerous requests, rather than specific known vulnerabilities. The challenge with this approach is the firewall can only look at each http request in isolation, without knowledge of how any api or application will interpret those requests. The more general the rule, the more likely it is to prevent legitimate requests.
With "anomaly scoring" the Azure WAF with newer rulesets attempts to mitigate this "false positives" problem by assigning a score to each rule, and blocking only if the total score for a request exceeds a set threshold. This is a heuristic that is difficult to tune - particularly as the content of requests will vary. An api could work most the time, and based entirely on variable user-supplied or arbitrarily encoded content, appear to randomly fail on some requests.
For the easyauth authentication flow, there are 4 rules that will cause requests to be blocked and require policy applied. One matches any percent encoded data, which is part of the 'state' param of the callback request, and the other three match base64 encoded data in general, which are used for 'code' and 'id_token' in the callback request and the cookie fields 'AppServiceAuthSession' and 'Nonce' in subsequent requests.
"Multiple URL Encoding Detected" (WARNING)
Implementation:
Pattern match \%\w at ARGS.
This matches any percent sign with a following character, %ile for example. The common form of an encoded query string, like "redir=%2F" to indicate where to go next as in the auth flow also triggers.
"Restricted SQL Character Anomaly Detection (args): # of special characters exceeded (12)" (WARNING)
The Microsoft rules documentation suggests disabling this rule entirely due to "Too many false positives" which is good advice.
Implementation:
Pattern match ((?:[~!@#\$%\^&\*\(\)\-\+=\{\}\[\]\|:;"'´’‘`<>][^~!@#\$%\^&\*\(\)\-\+=\{\}\[\]\|:;"'´’‘`<>]*?){12}) at ARGS.
This will not match things that might be SQL injection and will match very simple content:
> re.test("Robert'; DROP TABLE Students;--")
false
> re.test("------------")
true
Will always match on long enough base64 data as - is in the alphabet.
"SQL Comment Sequence Detected" (CRITICAL)
The Microsoft rules documentation mentions this can be replaced by MSTIC rule 99031002.
Implementation:
Pattern match (?:/\*!?|\*/|[';]--|--[\s\r\n\v\f]|--[^-]*?-|[^&-]#.*?[\s\r\n\v\f]|;?\x00) at ARGS.
This matches simple sequences such as "-- " and " # " that are likely to appear in a wide variety of content.
Will always match against long enough base64 data as -- followed by - can appear.
"SQL Hex Encoding Identified" (CRITICAL)
Implementation:
Pattern match (?i:(?:\A|[^\d])0x[a-f\d]{3,}) at REQUEST_COOKIES.
Will match valid base64 sequences like X0X0fA as well as other forms of hex encoded data such as used in html or css.
The content of this repo is free software (and documentation), you may redistribute and modify it under the terms of the GPLv3+ while the exclusion descriptions within the bicep script I would consider to be non-creative and may be extracted and used as per public domain.