What would be the best way to mitigate Azure Application Gateway WAF False Positive?

Question

We have a Web API which uses the REST semantics and is protected using the Azure's Application Gateway using a Web Application Firewall. The Web App consuming this API can send in any type of data in a JSON format but what is happening is that some strings are triggering the Web Application Firewall's rules for SQL Injection. Here is the error log I am seeing -

Message - Detects MySQL comment-/space-obfuscated injections and backtick termination
instanceId_s - appgw_3
SourceSystem - Azure
clientIp_s - 103.149.149.193
ruleSetType_s - OWASP
ruleSetVersion_s - CRS 3.1
ruleId_s - 942200
ruleGroup_s - REQUEST-942-APPLICATION-ATTACK-SQLI
action_s - Matched
details_message_s -     
Pattern match (?i:(?:(?:(?:(?:trunc|cre|upd)at|renam)e|(?:inser|selec)t|de(?:lete|sc)|alter|load)\\s*?\\(\\s*?space\\s*?\\(|,.*?[)\\da-f\"'`][\"'`](?:[\"'`].*?[\"'`]|(?:\\r?\\n)?\\z|[^\"'`]+)|\\Wselect.+\\W*?from)) at ARGS.

details_data_s - Matched Data: , THE\" found within ARGS:filters.value: \"COMPANY, THE\"
details_file_s - REQUEST-942-APPLICATION-ATTACK-SQLI.conf
details_line_s - 683
policyId_s - 54#default
policyScope_s - Global

The POST JSON body looks something like the following -

{
  "clientSide": false,
  "first": 0,
  "rows": 20,
  "sorting": [
    {
      "field": "rank",
      "order": 1
    }
  ],
  "filters": [
    {
      "field": "name",
      "value": [
        "\"COMPANY, THE\""
      ],
      "matchMode": "in"
    },
    {
      "field": "global",
      "value": [],
      "matchMode": "contains"
    },
    {
      "field": "globalFilterFields",
      "value": [
        "distName"
      ]
    }
  ]
}

My question is how can we fix this issue and what is the generally recommended approach?

1. I can Base64 encode the entire payload every time before sending it to the API and have it decode it but then I wonder if that kind of defeats the purpose of having a WAF in front of the API since it will not be able to detect even malicious attempts because they will be base64 encoded.
2. I can try adding an exclusion to the Application Gateway's Firewall but I have not been able to find out a way to add an exclusion for the POST body. Also, since the Web App allows users to enter arbitrary data in the sense that things like double quotes etc, are allowed, I don't want to add hundreds of rules (App Gateway WAF allows 100 custom rules I believe) like this.

Are there any other ways to solve this issue?

Answer 1

Half-serious response: throw the whole thing away, WAFs are somewhere between "more trouble than they're worth" and "worse than useless". They're like antivirus except their detection (both sensitivity and accuracy) is somehow even worse, they break your site when they misbehave, and there's no way for a legit user to bypass them. The protection they provide is marginal; a competent attacker or even well-written script can almost always bypass them.

(Reasons this is only half-serious: there are a few things that a WAF can meaningfully detect with confidence, the alerting can be useful even if the blocking is overzealous, and WAFs provide a central management point for other useful traits like blocking suspicious source IPs or 0-day known exploits... though how well they do at that is highly variable. There is perhaps no single thing that a WAF is the best answer for, but they are a convenient place to put a lot of occasionally-valuable checks.)

---

Fully-serious response: you should be able to disable that rule or at least downgrade it to "notify" from "block" (possibly even only for that endpoint) and there's no good reason not to. Preventing SQL injection is a solved problem - just use parameterized queries and avoid any form of string concatenation in SQL - and it's impossible to prevent with a regex anyhow. You could also possibly enable a mode between "notify" and "block" where e.g. allow the first nine flagged requests in a minute are logged but allowed, and the tenth or later one gets blocked... but of course that risks filling up logs with false positives and blocking legit users during high-traffic periods.

Base64 encoding is an interesting idea; some (few) WAFs will recognize this and decode it, but most will ignore it. The reason not to do that, though, is less about the WAF and more about the actual security you should have behind it; any time you're adding encoding and decoding to your flow, you risk performing a validation or escaping step (e.g. for XSS) on the encoded data, which of course finds nothing. (It is also true that, assuming the WAF doesn't itself recognize and decode base64, you'll be in effect completely turning off its content rules for that endpoint, even the ones that are theoretically adding value.)

---

You asked why WAFs are so popular then, and it's a fair question. In my experience, the answer is some combo of:

• Lying vendors promising they can solve all your security problems[*] to ignorant and credulous executives[**]
• People coming to expect it (encouraged by the same vendors, of course) and thus making it a contractual requirement to have one
• A "checkbox" approach to security where the question is "do you have XSS protection" and not "has anybody competent ever checked if they can get XSS on your site"
• Lots of people who can't be bothered to read even the basics of web security and thus deploy sites with gaping holes and, when this bites them, take the least-effort approach to "fixing" the problem
• The fact that there are in fact a lot of script kiddies out there trying dead-easy-to-block attacks, so a WAF sure looks like it's providing value by blocking them all (and is in fact providing some value, if you're in the group mentioned in the previous point)
• Actual value even to people who have put in any meaningful security effort, in the form of e.g. malicious IP filtering and similar checks that it's reasonable to delegate to external software. Even though in most cases you could do better with a fine-grained and context-aware filter implemented in your server, it'd just be more effort to create and maintain

[*] Usually described as "Prevent the entire OWASP Top 10" or similar. This is neither accurate (there are several items in the current top 10 list that a WAF will never be able to handle even in theory), nor sufficient (lots of critical security vulnerabilities are not in the current top 10, though some have been in the past).
[**] As far as I can tell, there is simply no accountability in this field, and the vendors know this so they just don't care. My employer recently was faced with the requirement to procure a WAF in order to close a big contract. Every vendor promised us a miracle solution. Every time, I was able to find multiple pages of bypasses in under a day's work. They never cared. We eventually picked one - a really big, well-trusted company's product, you've heard of them - largely on the basis of "easy to deploy, it'll stay out of our way, and doesn't cost too much". Our bug bounty testers didn't even break their stride, using bypasses I hadn't even noticed in those quick tests.