Web Application Firewall Cookie Exclusions only exclude Value checking not Name checking

Ben Duguid 211 Reputation points
2022-06-28T17:46:16.937+00:00

The Azure Front Door Web Application Firewall is blocking a number of valid requests due to false positives caused by cookie names.

We have the Default Ruleset 1.1 enabled in "Prevention" mode, and a number of requests coming back from OpenId/OAuth sign-ins are being blocked by XSS and SQLI rules based on the name of the cookie (rather than the value in those cookies).

The ASP.NET OpenId connect implementation generates a cookie with a name like:
OpenIdConnect.nonce.2giICEskV2Ef+G5+17YXnqA5KjVQoFNK9Ybyt36ONiU=

These names then fall foul of either XSS, SQL Injection or SQL Comment rules:

[  
  {  
    "matchVariableName": "CookieName",  
    "matchVariableValue": "OpenIdConnect.nonce.2giICEskV2Ef+G5+17YXnqA5KjVQoFNK9Ybyt36ONiU="  
  }  
]  
 

Blocked by Microsoft_DefaultRuleSet-1.1-XSS-941120

I have set up the following exclusion for the ruleset:

RequestCookieName Starts With OpenIdConnect.nonce  
 

However this doesn't help as the exclusion is only run when looking at the value of the cookie, which is usually OK, and as you can see from the logged value, it's the CookieName that's triggering the error.

Just adding a few more points.

The issue seems to come from the default implementation of the Asp.NET OpenId Connector, specifically around handling the Nonce cookie.

The process flow is:

Client Application generates a nonce, stores that in a cookie with the nonce in the cookie name, and sends in the request to the server.

User authenticates with the server and is returned to the client with a nonce included in the token.

Client Application confirms that:

  1. Nonce exists on returned response.
  2. Cookie with name containing the nonce exists.
  3. Cookie with name containing the nonce includes the nonce as its value.

Default implementation of Write Cookie can be seen here:

private void WriteNonceCookie(string nonce)  
{  
    if (string.IsNullOrEmpty(nonce))  
    {  
        throw new ArgumentNullException(nameof(nonce));  
    }  
  
    var cookieOptions = Options.NonceCookie.Build(Context, Clock.UtcNow);  
  
    Response.Cookies.Append(  
        Options.NonceCookie.Name + Options.StringDataFormat.Protect(nonce),  
        NonceProperty,  
        cookieOptions);  
}  

And the Protect method is:

public string Protect(TData data, string? purpose)  
{  
    var userData = _serializer.Serialize(data);  
  
    var protector = _protector;  
    if (!string.IsNullOrEmpty(purpose))  
    {  
        protector = protector.CreateProtector(purpose);  
    }  
  
    var protectedData = protector.Protect(userData);  
    return Base64UrlTextEncoder.Encode(protectedData);  
}  

As you can see, the cookie name includes a Base64 encoded string, which can often fall foul of SQL Injection, Hex Encoding and Cross Site Scripting firewall rules. As these are all fairly common attacks vectors (albeit able to be handled elsewhere in the application code base) it seems counterproductive to disable these rules, when a solution would be either exclude cookie names from the processing, or at least allow the exclusions to include the name of the cookie as well as its value.

Azure Front Door
Azure Front Door
An Azure service that provides a cloud content delivery network with threat protection.
634 questions
Azure Web Application Firewall
{count} vote

1 answer

Sort by: Most helpful
  1. ChaitanyaNaykodi-MSFT 24,666 Reputation points Microsoft Employee
    2022-06-29T18:54:39.857+00:00

    Hello @Ben Duguid , thank you for reaching out.

    Your understanding here is correct when the matchVariableName is CookieName, it means the name itself is triggering the rule. Rule exclusion has no support for these matchVariableNames at this time. This is currently documented here. The work around in this scenario will be to disable the rule triggering this issue.

    I am creating an internal feature request item for this scenario and also request you to create a feedback item on the Azure Feedback portal.

    Please let me know if you have any additional concerns, I will be glad to continue with our discussion. Thank you!