Azure Front Door WAF is blocking .AspNet.ApplicationCookie

Question

I'm wondering if anyone else has had this issue with Azure Front Door and the Azure Web Application Firewall and has a solution.

The WAF is blocking simple GET requests to our ASP.NET web application. The rule that is being triggered is DefaultRuleSet-1.0-SQLI-942440 SQL Comment Sequence Detected.

The only place that I can find an sql comment sequence is in the .AspNet.ApplicationCookie as per this truncated example: RZI5CL3Uk8cJjmX3B8S-q0ou--OO--bctU5sx8FhazvyvfAH7wH. If I remove the 2 dashes '--' in the cookie value, the request successfully gets through the firewall. As soon as I add them back the request gets blocked by the same firewall rule.

It seems that I have 2 options. Disable the rule (or change it from Block to Log) which I don't want to do, or change the .AspNet.ApplicationCookie value to ensure that it does not contain any text that would trigger a firewall rule. The cookie is generated by the Microsoft.Owin.Security.Cookies library and I'm not sure if I can change how it is generated.

Mcneil

Answer 1

I ran into same problem as well.

If you have a look to the cookie value: RZI5CL3Uk8cJjmX3B8S-q0ou--OO--bctU5sx8FhazvyvfAH7wH there are two -- which is the potentially dangerous SQL command that can comment out your SQL command that you're going to query. An attacker may run their command instead of your command - after commenting out your query.

But, obviously, this cookie won't run any query on the SQL side and we are sure about that. So we can create rule exclusions that won't run specific conditions.

Go to your WAF > Click Managed Rules on the left blade > Click manage exclusions on the top > and click add

In your case, adding this rule would be fine:

Match variable: Request cookie name Operator: Starts With Selector: .AspNet.ApplicationCookie

However, I use Asp.Net Core 3.1 and I use Asp.Net Core Identity. I encountered other issues as well, such as __RequestVerificationToken.

Here is my full list of exclusions. I hope it helps.

PS I think there is a glitch at the moment. If you have an IP restriction on your environment, such as UAT, because of these exclusions Web Application Firewall is by-passing the IP restriction and your UAT site becomes open to the public even if you have still custom IP restriction rule on your WAF.

Schizogenesis

I had to add all your exclusions, and more - rules 942440 & 942450 are particularly annoying - they blanket-match "--" anywhere, which seems ridiculously simplistic, especially given the cost of Azure WAF. In the end I conceded and disabled them :-/ – Printmaking

Correct me if I'm wrong, but allowing access for any requests that have a cookie with cookiename .AspNet.ApplicationCookie, doesn't this simply create a free ticket to bypass any WAF? – Kirkham

Disregard my above comment. I figured out that only applies to Custom rules. With Exclusion lists, you can add custom rules for a specific rule, instead globally. – Kirkham

Answer 2

I ran into something similar and blogged about it here: Front Door incomplete first request.

To test this I created a web application and put it behind the Front Door service. In that test application I iterate over all the properties of the HttpContext.HttpRequest and print them out. As far as I can see right now, there are two properties that have differences between a direct request and a request through Front Door. Both the AcceptTypes and the UserLanguages property are empty for Front Door requests, while they are absolutely filled in when directly accessing the test application.

I’m not quite sure what the reason is for the first Front Door request to be different from a direct request. Is it a bug? Is it intentional and if so, why? Or is it because Front Door is developed using a framework that doesn’t support these properties, having them be empty when being forwarded?

Unfortunately I didn't find a solution to the issue, but to answer the question if anyone else is experiencing this: I did experience something similar.

Mantle

Answer 3

Seems that the cookie got corrupted , as I was comparing the fields that existed before vs a healthy cookie, my guess is maybe somewhere in the content of the field it is being interpreted as a truncate sql statement and probably triggering the rule. Still to determine if this is true and/or what cause it.

Thornburg

Answer 4

I ran into this issue but the token was being passed through via the request query rather than via a cookie. In case it might help someone, for the specified host I had to allow via a custom rule doing a regex match on the RequestUri, using the following regex (taken from the original managed rule):

:\/\\\\*!?|\\\\*\/|[';]--|--[\\\\s\\\\r\\\\n\\\\v\\\\f]|--[^-]*?-|[^\\u0026-]#.*?[\\\\s\\\\r\\\\n\\\\v\\\\f]|;?\\\\x00

Sextan