Waf Charm

Blog

AWS WAF, WafCharm

AWS WAF has started providing in-line regular expressions

This post was originally written in Japanese in the past.

Table of Contents

  1. 1. Introduction
  2. 2. How to use the feature
  3. 3. Comparison with regex pattern set
  4. 4. Changes in WafCharm
  5. 5. Conclusion

1. Introduction

In-line regular expressions have been provided from September 23rd, 2021 (PDT).
Before the release, you had to add a regex pattern set to use regular expressions. With this update, you can enter regular expressions directly in the rules.

AWS WAF now offers in-line regular expressions

*This feature is not available in AWS WAF Classic.

2. How to use the feature

Select “Matches regular expression” under the Match type on the rule creation page.

auto

Enter a regular expression in the “Regular expression” field.

auto

When you look at the created rule in JSON format, RegexMatchStatement is declared with the regular expression written under RegexString.

````
{
  "Name": "test",
  "Priority": 0,
  "Action": {
    "Block": {}
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "test"
  },
  "Statement": {
    "RegexMatchStatement": {
      "FieldToMatch": {
        "Body": {}
      },
      "TextTransformations": [
        {
          "Type": "URL_DECODE",
          "Priority": 0
        }
      ],
      "RegexString": "test*test|^/test"
    }
  }
}


````

3. Comparison with regex pattern set

Before this feature, we had to configure a regex pattern set beforehand and create a rule that refers to the regex pattern. Because there are limitations to the number of pattern sets you can use, there was a technique to reduce the number of pattern sets by combining string match conditions, as shown below.

Example: specify “/user/[user ID]/view” in URI

  • If not using regex
    Starts with /user/ AND ends with /view
  • If using regex
    ^/user/[a-z0-9]+/view$

The limitations written in the official document and those we could confirm by testing are listed below.

Limitations in pattern sets

  • You can set up to 10 pattern sets
  • You can define up to 10 regular expressions in one pattern set
  • Maximum number of characters you can use in a regular expression is 200

Limitations in in-line regex

  • Maximum number of characters you can use in a regular expression is 512

It seems like in-line regex has fewer limitations compared to the pattern sets.

If you have a rule that uses string match condition with OR condition, using in-line regex will definitely reduce the amount of WCUs you use.
For example, if you want to create a rule that matches one of these four strings, “spring,” “summer,” “autumn,” or “winter,” you will use 50 WCUs if the rule does not use regular expressions.

````
{
  "Name": "seasons",
  "Priority": 0,
  "Action": {
    "Block": {}
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "seasons"
  },
  "Statement": {
    "OrStatement": {
      "Statements": [
        {
          "ByteMatchStatement": {
            "FieldToMatch": {
              "QueryString": {}
            },
            "PositionalConstraint": "CONTAINS_WORD",
            "SearchString": "spring",
            "TextTransformations": [
              {
                "Type": "URL_DECODE",
                "Priority": 0
              }
            ]
          }
        },
        {
          "ByteMatchStatement": {
            "FieldToMatch": {
              "QueryString": {}
            },
            "PositionalConstraint": "CONTAINS_WORD",
            "SearchString": "summer",
            "TextTransformations": [
              {
                "Type": "URL_DECODE",
                "Priority": 0
              }
            ]
          }
        },
        {
          "ByteMatchStatement": {
            "FieldToMatch": {
              "QueryString": {}
            },
            "PositionalConstraint": "CONTAINS_WORD",
            "SearchString": "autumn",
            "TextTransformations": [
              {
                "Type": "URL_DECODE",
                "Priority": 0
              }
            ]
          }
        },
        {
          "ByteMatchStatement": {
            "FieldToMatch": {
              "QueryString": {}
            },
            "PositionalConstraint": "CONTAINS_WORD",
            "SearchString": "winter",
            "TextTransformations": [
              {
                "Type": "URL_DECODE",
                "Priority": 0
              }
            ]
          }
        }
      ]
    }
  }
}

````

When you use in-line regex, you will be using 13 WCUs.
In in-line regex, using up to the maximum of 512 characters will not change the amount of WCUs you use.

````
{
  "Name": "seasons_regex",
  "Priority": 6,
  "Statement": {
    "RegexMatchStatement": {
      "RegexString": "spring|summer|autumn|winter",
      "FieldToMatch": {
        "QueryString": {}
      },
      "TextTransformations": [
        {
          "Priority": 0,
          "Type": "URL_DECODE"
        }
      ]
    }
  },
  "Action": {
    "Block": {}
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "seasons_regex"
  }
}

````

This is an extreme example, but we hope you can see that this feature could reduce the amount of WCUs you need.

4. Changes in WafCharm

There are no changes from the in-line regex feature.
However, with less limitations, we could expect less WCU usage, which will allow us to add more rules. Please look forward to improvements in WafCharm through in-line regex.

5. Conclusion

With this update, we believe that when you can, using an in-line regex would be the most appropriate choice when creating a rule. If you have existing rules that use string match conditions, consider using in-line regex instead to reduce WCUs.