CR DenyRules

Airlock Microgateway has built-in deny rules to block malicious requests to upstream web applications. This deny rule set is constantly evolving and updated to respond to the latest threats.
Each deny rule is identified by a deny rule key that can be referenced for configuration purposes. Each ruleKey refers to different attack types such as SQL injection, XSS, GraphQL, TEMPLATE injection, etc.

  • The CRD DenyRules allows configuring the following in the CR:
  • The security level of the applied deny rules.
  • The threatHandlingMode (i.e., Block or LogOnly) can be configured globally and on the ruleKey level. Non-deny rule depending threatHandlingMode can be configured on feature level, i.e. Limits, OpenAPI and GraphQL within their CR.
  • Deny rule overrides to change settings (e.g. security level or threat handling mode) of specific deny rules.
  • Deny rule exceptions for requests that match one or more deny rules but should not be blocked. Exceptions can be configured and fine-tuned to reduce the number of false positives using blockedData and/or requestConditions based on various characteristics.
  • The definition of custom deny rules.

This CR needs to be referenced in the CR ContentSecurity.

Example configuration

For the default and an example configuration including custom rules, see CR DenyRules reference documentation.

  • The example covers:
  • spec.request.builtIn.settings – global deny rule settings.
  • spec.request.builtIn.override – deny rule override, to override the global deny rule settings for some deny rules.
  • spec.request.builtIn.exceptions – deny rule exceptions.
  • spec.custom.rules – custom deny rule definition.

In addition to the API Reference documentation, this article adds helpful background information for the available configuration options.

Security levels

Different security levels can be configured on global and deny rule levels. This makes it possible to configure the balanced processing of requests with a high level of security and a low number of false positives simultaneously.

Global level

Explanation

Unfiltered

In level Unfiltered, no deny rules are applied. This means, no requests will be blocked.

Basic

Deny rules in level Basic focus on a low false-positive rate, simplifying the integration of applications. Note, however, that certain attack variants may not be covered.

  • Indications for using the level Basic:
  • Level Standard requires too many exceptions.
  • The upstream application access is protected by authentication.

Standard

Level Standard is the default setting. It provides strong filters and a low false-positive rate. Exceptions may be required for input fields containing syntactical elements similar to JavaScript or SQL.

  • Indications for using the level Standard:
  • The application is complex or dynamic.
  • The application uses many input fields with unrestricted input values, e.g., free texts or comments.
  • Application access is protected by upstream authentication.
  • Level Strict requires too many exceptions.

Strict

Level Strict focuses on blocking many potential attack variants. This level is recommended for very sensitive applications and typically requires some integration effort.

  • Indications for using level Strict:
  • Login and critical pages are exposed directly to the Internet without upstream authentication.
  • The application is rather simple.
  • Application data is very sensitive (high risk).
  • Low code quality of an application.

Override global settings for specific deny rules

For fine-tuning, i.e., to reduce the number of false positives, the security level or the threat handling mode for individual deny rules may be configured differently from the global settings. To do so, configure non-global security levels for deny rules using the ruleKeys or the types element.

Deny rule exceptions

Deny rule exceptions can be defined for different data elements.

  • Data element types for exceptions:
  • blockedData for exceptions on blocked data elements, e.g., for blocked parameters, headers or JSON data.
    Note that blockedData only allows requests if the string triggering the false positive was in the configured parameter, header or JSON data.
  • requestConditions, to create exceptions for general characteristics of blocked requests, e.g. request path or originating remote IP.
  • Possible deny rule configuration options:
  • Define a deny rule exception only with blockedData:
  • This way, the configured exception is applied unconditionally to all paths, HTTP methods, remote IP addresses, ...

  • Define a deny rule exception with blockedData and requestConditions:
  • This is the recommended configuration, as it only applies the exceptions to requests that matches the requestConditions.

  • Define a deny rule exception only with requestConditions:
  • This configuration should be chosen carefully, as deny rule checks are not applied at all to requests which matches the requestConditions.

Note that exceptions will only reduce blocks if the configured exception covers all data elements that trigger deny rules.

For example, if an exception is configured to unblock search parameters, a request containing a search and a language parameter could still be blocked if the language parameter triggers a deny rule. The same mechanism applies to other blocked data elements such as parameters, headers or JSON data.

Deny rule exceptions for JSON content

Body data of requests with content-type header application/json are parsed as JSON content and might cause false positives. Deny rule exceptions can be defined for JSON keys or values based on the access log information. Additionally, exceptions can be restricted to a defined JSONPath. In the JSONPath expressions, wildcards (*) can be used, like in this JSONPath syntax reference.

Example:

{ 
  "books": [ 
    { 
      "title": "DevSecOps Starters Guide", 
      "author": "Joe Bloggs", 
      "stars": 723 
    }, 
    { 
      "title": "JSONPath for Geeks", 
      "author": "Jane Smith", 
      "stars": 27 
    } 
  ] 
}

This JSON example contains 6 key-value pairs (aka leaves), 3 pairs for each book. The values of the JSON leaves can be filtered with the corresponding JSONPath from the following table.

JSONPath          | Value 
------------------|---------------------------- 
$.books[0].title  | "DevSecOps Starters Guide", 
$.books[0].author | "Joe Bloggs", 
$.books[0].stars  | 723 
$.books[1].title  | "JSONPath for Geeks", 
$.books[1].author | "Jane Smith", 
$.books[1].stars  | 27
  • Additional JSONPath examples:
  • $..author – matches every leaf of the key author (Joe Bloggs and Jane Smith) in every book.
  • $.books[*].author – matches every leaf of the key author in all books.

For instance, an exception for all books of authors named Joe can be configured as follows.

Example:

copy
apiVersion: microgateway.airlock.com/v1alpha1
kind: DenyRules
metadata:
  name: my-webapp
 spec: 
  request: 
    builtIn:
      exceptions: 
        - blockedData: 
            json: 
              jsonPath: $.books[*].author 
              value: 
                matcher: 
                  contains: Joe
  • For deny rule exceptions, operators [] with expressions and script expressions are not supported. For example, $..book[?(@.age)].title does NOT work as JSONPath expression.
  • The JSONPath expression must always match a leaf. For example, $.books[*] does not contain a leaf and will not work, whereas $.books[*].author does.

Custom deny rules

Custom deny rules can be configured to complement the built-in deny rules.

  • Difference to built-in deny rules:
  • Custom rules can be added in the CR DenyRules.
  • Security levels and exceptions cannot be applied to custom deny rules.

If one of the configured rules matches a request, the ruleKey is included in the corresponding access log message. Therefore, we recommend using short, descriptive denominations for rule keys.

Note that the ruleKey must be a unique denomination and match ^[A-Z][A-Z0-9_]*$, e.g. ruleKey: MY_CUSTOM_KEY_01.