Azure WAF - OAuth 2.0 tokens, SQLi's, and false positives

Hello again, in this post I'm going to discuss another commonly noticed issue with web applications that use the OAuth protocol and sit behind an application firewall.

Azure Web Application Firewall will be used as an example but as you will read in the next paragraphs the example applies to every modern firewall solution. WAFs (Web Application Firewalls) come with a set of managed rules which are defined as

A pre-configured rule set is enabled by default. This rule set protects your web application from common threats defined in the top-ten Open Web Application Security Project (OWASP) categories. - Azure WAF definition

Managed rules can be disabled / enabled at will and also custom rules can be set based on a variety of criteria (coming up in the next blog post)

Now that theory is hopefully covered, time for the story. My team was recently notified about cases where users would be denied access based on the firewall rules. After asking a few basic questions about their whereabouts we understood that this had to be a false positive.

So the next step was of course was to check the firewall logs, and the issue was apparent in an instant. Below is the log entry for that specific user. The important bits here are the ruleName property which contains the rule that was triggered which is in this is 942450 - SQL Hex Encoding Identified. A simple google search is enough to validate the assumption, the second property we'll focus is the matches array which contains information about the parameter that trigged the rule and which part of the string.

{
  "time": "2022-03-23T16:10:15.2564171Z",
  "resourceId": "/SUBSCRIPTIONS/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXX/RESOURCEGROUPS/XXXXXXX/PROVIDERS/MICROSOFT.NETWORK/FRONTDOORS/XXXXXXXX",
  "category": "FrontdoorWebApplicationFirewallLog",
  "operationName": "Microsoft.Network/FrontDoor/WebApplicationFirewallLog/Write",
  "properties": {
    "clientIP": "XX.XX.XX.XX",
    "clientPort": "12345",
    "socketIP": "XX.XXX.XXX.XXX",
    "requestUri": "https://www.myservice.co.uk:443/api-auth/oauth2/token",
    "ruleName": "DefaultRuleSet-preview-0.1-SQLI-942450",
    "policy": "azwafpolicy",
    "action": "Block",
    "host": "www.myservice.co.uk",
    "trackingReference": "XXXXXXXXXXXXXXXXX",
    "policyMode": "prevention",
    "details": {
      "matches": [
        {
          "matchVariableName": "PostParamValue:id_token",
          "matchVariableValue": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ilg1ZVhrNHh5b2pORnVtMWtsMll0djhkbE5QNC1jNTdkTzZRR1RWQndh"
        }
      ],
      "msg": "SQL Hex Encoding Identified",
      "data": "Matched Data: eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ilg1ZVhrNHh5b2pORnVtMWtsMll0djhkbE5QNC1jNTdkTzZRR1RWQndh found within PostParamValue:id_token: eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ilg1ZVhrNHh5b2pORnVtMWtsMll0djhkbE5QNC1jNTdkTzZRR1RWQndh"
    }
  }
}

Now that we know what is causing the blocked request, it is time to open the managed rules section of the WAF Policy and disable the rule. Once the rule was disabled the user was able to access the application.

Some of the SQLi rules known to cause false positives

You can read more about false-positives in Microsoft's official documentation.

As always, thank you for reading this post. D

Featured Image source: What is Azure Web Application Firewall on Azure Application Gateway? - Azure Web Application Firewall | Microsoft Docs

Comments

Tags