Recently I’ve been working on a Sitecore site that is using Azure App Gateway, and it is using the Web Application Firewall (WAF) features of that too. Broadly, I’ve been quite impressed, but I did come across a few problems.

OWASP publish a set of rules used in ModSecurity to try to identify anomalous traffic. These rules then total into a score of “how anomalous this request is”. Finally, there is one rule that checks that score, and potentially blocks traffic based on it.

We found we were getting traffic blocked. Here’s what we found.

942430 – SQL Injection Character Anomaly Usage

This rule attempts to make SQL Injection attacks more difficult. It checks for special characters, and adds score if there are more than 12 of them. However, those special characters include - = % & . That’s a problem, as these are valid characters in a URL.

Consider the hyphen. A user creates a folder called “i love nursery rhymes” and then a page called something like “mary had a little lamb its fleece was white as snow”. This will have a Sitecore path of:

/i love nursery rhymes/mary had a little lamb its fleece was white as snow

Sitecore renders that URL replacing the spaces with hyphens:

/i-love-nursery-rhymes/mary-had-a-little-lamb-its-fleece-was-white-as-snow

… and boom, your URL contains 13 hyphens, and the firewall blocks it. However, it’s a valid URL. Note also the additive nature of characters in folders – so you don’t need a peculiarly named item, if you have a deep tree structure.

That’s pretty much what happened to our customer. Also note that the structure of the site – and therefore the URLs – is down to our content editors. These are people who shouldn’t be forced to count spaces in a URL.

Worse, % is used if you need to URL encode special characters, which is hardly uncommon. What if someone searches for a bit of text that has punctuation that needs encoded? Again, you can get blocked.

And & is used to separate query string parameters. I have seen search pages which have more than 13 parameters, by the time you’ve included filtering, sorted, pagination, etc. That would be blocked.

12 characters seems to be an arbitrary level. Why is 13 “special” characters too much, but 12 fine? No idea.

We disabled this rule, mainly because asking content editors to count characters when creating items seemed so unreasonable. Also, we’re not making any direct SQL connections from our solution, so SQL injection is not something we are very worried about.

942440 – SQL comment sequence detected

This rule attempts to make SQL Injection attacks more difficult. It checks for double hyphens ( — ) which are a SQL comment. Unfortunately, this is a pretty naive test. Double hyphens can be valid data in requests.

In particular we found double hyphens in form fields – in the __RequestVerificationToken field, which is part of a defence against CSRF attack. And it’s a standard ASP.NET technology.

We also found double hyphens in the Google reCAPTCHA token that is submitted by the form – which is a defence against bots.

In both those places, a double hyphen is valid data. And we can’t change how either of those technologies work.

I can also imagine double hyphens existing inside cookies too – and being valid there too.

We disabled this rule. It was particularly troublesome as it was intermittent – most user’s tokens/cookies/etc. might be fine, but some unlucky few would get ones with double hyphens. Yay.

Side notes:

These rules are from the OWASP recommended rules, so it’s not a problem with the Azure WAF itself. But it does implement these rules, and frankly, some of these are not entirely helpful.

I’ll update this article if I find more examples of unhelpful rules.