Azure WAF tuning with AD B2C applications

Azure Active Directory B2C (Azure AD B2C) provides business-to-customer identity as a service to get single sign-on access to your applications and APIs. This provides an authorization layer for applications hosted behind Application Gateway and Azure Front Door. However, some false positives may occur during the final authentication process.

When working on false positives, a good practice is to look out for results with a similar tracking reference. (See Understanding WAF logs). Tracking references give an overall idea of the added scores that led to a block. This can be seen in logs with action_s for a “block” entry, followed by a series of action_s for “Anomaly scoring”. By creating an exclusion on the matched field, you can effectively reduce the score and remediate the false positive.

 

When Azure Active Directory (AAD) is used for authentication in ADB2C with generic OpenID Connect, the WAF tends to block legitimate access, this is common with SQL rules such as "942440 SQL Comment Sequence Detected". This rule has now been replaced by the Microsoft Threat Intelligence Collection rule 99031002 in the Default Rule Set (DRS). By upgrading to the DRS ruleset, some of these false positives are addressed. This can be seen in logs with action_s for a “block” entry, followed by a series of action_s for “Anomaly scoring”. By creating an exclusion on the matched field, you can effectively reduce the score and remediate the false positive.

Symptom: The application works fine with AAD Authentication when accessed directly. However, when accessed via an Azure Frontdoor or Application Gateway URL, authentication works but it is unable to return the application interface or the redirect URI of the backend resource. The log shows this request is blocked by WAF. If you try again, it might not trigger, marking an inconsistency in the behavior. The main culprit is the reply URI after authentication has been granted.

There are certain expectations of the reply URL configuration. These include:

• The reply URL must begin with the scheme https, unless you use a localhost redirect URL.
• There is a maximum limit of 256 characters for each redirect URI you add to an app registration.
• The reply URL is case-sensitive. Its case must match the case of the URL path of your running application. For example, if your application includes as part of its path “.../abc/response-oidc, do not specify .../ABC/response-oidc” in the reply URL. Because the web browser treats paths as case-sensitive, cookies associated with “.../abc/response-oidc” may be excluded if redirected to the case-mismatched “.../ABC/response-oidc” URL.
• The reply URL should include or exclude the trailing forward slash as your application expects it. For example, https://contoso.com/auth-response and https://contoso.com/auth-response/ might be treated as nonmatching URLs in your application.
• Redirect URIs do not support the special characters - ! $ ' ( ) , ;
• For more information:  see Redirect URLs restrictions

Once you have ensured that the actual reply URLs match the configured reply addresses in the application, you can then proceed to tune your WAF following the applicable steps below.

 

1. As mentioned earlier, the reply URL is used to return authentication id_token, which is used to provide access to the back-end resource. This URL is often flagged by Azure WAF and blocked by known rule IDs. This value may be excluded using the _RequestVerificationToken and other application specific attributes. Another known attribute AspNet.ApplicationCookie, may also be found in the match, triggered if your cookie contains double dashes (--). For your asp.net application, you can view the false positive using details_msg_s field in your logs. Here are known match variable fields that often trigger blocks and may be entered in your exclusions list. Make sure to apply this exclusion only on the rule group level and not globally.

 

Field	Operator	Selector
RequestCookieNames	StartsWith	.AspNetCore.Correlation.oidc.
RequestBodyPostArgNames	StartsWith	__RequestVerificationToken
RequestCookieNames	StartsWith	.AspNetCore.OpenIdConnect.Nonce.
RequestBodyPostArgNames	Equals	id_token
RequestBodyPostArgNames	Equals	state
RequestCookieNames	StartsWith	.AspNetCore.Cookies

 

2. For developers registering a SAML application in Azure ADB2C, the single sign-on may not work while using Azure WAF once you switch from detection mode to prevention mode. The SAML value or assertion can trigger anomaly detection for DefaultRuleSet-1.0-SQLI-942430. The first step is to ensure the SAML request is encoded into the location header using HTTP redirect binding. For more information, see error AADSTS750054. This needs to be verified in Azure AAD before WAF troubleshooting. You can then confirm from the log that SAML response is triggering the rule group 942430, which matches the pattern for occurrence of 12 special characters like colons, semi colons etc.

 

 

To view a SAML response, you can use a browser or a 3^rd party tool like fiddler.

 

 

In this case, exclusion can be created with the matchvariable name keypair as used in the “RequestedHeaderValue” example in this table

[{“matchVariableName”: “PostParamValue:SAMLResponse”}].

 

PostParamValue:SOME_NAME

Request body POST args name Equals SOME_NAME

 

 

3. Custom rule to Redirect URI.

As explained in the WAF tuning documentation, the redirect URI option in custom rules may be used as the condition to allow list of redirect URIs of each of the application federated with Azure B2C. Custom rules are processed before managed rules. A custom rule can be used for a more granular approach as it permits a combination of multiple match parameters to trigger an action such as a string and a URI. See this example in documentation for details.

4. Custom rule with regular expression.

Custom rules may be used to exclude inspection on a reply URL to the grant access to the back-end application. You can combine certain strings or URLs which are trusted in the custom rules. As an example, the following expression may be used to allow only requests from contoso.com/getAToken or jwt.ms/getAToken when configured in a custom rule.

 

((http|https):\/\/)(www.)?(contoso\.com/getAToken||jwt\.ms/getAToken)

 

 

 

 

In conclusion, WAF log components play an important role in the information you need to reduce the false positives. Ensure the latest ruleset is used to address factors that increase the anomaly score. Disabling of managed rules should only be a last resort to reduce the risk of exposure to web vulnerabilities.  

 

Resources

• Tuning Web Application Firewall (WAF) for Azure Front Door | Microsoft Learn
• Troubleshoot - Web Application Firewall on App Gateway | Microsoft Learn
• Azure WAF Tuning for Web Applications - Microsoft Community Hub
• New Threat Detections for Azure WAF - Microsoft Community Hub