*This entry was originally written in Japanese in the past based on AWS WAF Classic.

Table of Contents

1. Introduction
2. String match conditions
3. Regular expression match conditions
4. Example usage for false positives
5. Example of how to create exclusion rules
6. Conclusion

Introduction

In the last part of this series, we will take a look at features of string match conditions and regular expression (regex) match conditions and their example usages.

If you haven’t looked at Part 1 and Part 2 of this series yet, you could better understand the topics discussed in this post by reading the last two parts beforehand.

• Part 1: AWS WAF Classic Explained - Basic Structure
• Part 2: AWS WAF Classic Explained - Relationship between Conditions and Filters
• Part 3: AWS WAF Classic Explained - Structure of string and regex matching and examples usage (this post)

In this part, we will focus on the essential structure to fully understand AWS WAF Classic: string and regex match conditions. We will add strings to match with string match conditions in filters. Similarly, you add regular expressions to match with regex match conditions in filters.

String match conditions

You can prevent various attacks with conditions that allow or block requests based on strings included in the requests. By specifying match types (i.e., exactly matches, starts with, or ends with), you can limit the effect to target accesses. The caveat is that the maximum length of a string is 50 bytes, so there is a limit to strings you can specify. You can match the string to prevent attacks if you know attack patterns for a particular vulnerability.

Regular expression match conditions

This condition allows or blocks a request if it matches the regex pattern and strings in the request. This is a more flexible condition compared to the string match condition. The maximum length is 70 bytes. The difference between typical conditions and filter relationships is that there is a filter called “Regex pattern set” to group regex patterns.

Below is a diagram of the structure you should understand before you create the regex match condition.

Vocabulary

• Regex match condition: a condition that has regex pattern set applied
• Regex pattern set: a package that groups regex pattern strings
• Regex pattern string: actual content of the regex pattern set. Strings that define what kind of attacks are detected

Steps to create regex match condition

1. Select “Regex match” from String and regex matching
2. Create regex pattern set in the Filter settings section
3. Apply the created filter to the condition
4. Create condition
5. Regex match condition is created

The regex pattern set you created in step 2 above can also be used when creating other regex match conditions. However, certain restrictions exist when creating regex match conditions and regex pattern sets.

Restrictions

• You can add maximum of 10 regex match conditions in one AWS account
• You can add maximum of 5 regex pattern sets in one AWS account
• You can add maximum of 10 regex pattern strings in one regex pattern set

To sum up, in order to create a condition for a regex match, you need to add filter groups with regular expressions written to regex pattern sets. Then, you must apply the regex pattern set to the condition to complete the process.

Regular expressions support most of the Perl Compatible Regular Expressions (PCRE).
The official information is provided in the document below.

Creating a regex match condition

Example usage for false positives

If you encounter false positives

One of the issues in using WAF is what to do when you encounter false positives. There are two main actions you can consider. One, if there are issues in applications, remediate the issues. Two, disable the detection in WAF. Both actions have benefits and disadvantages but ensure there are no security issues that could occur when selecting the exclusion method.

Temporary action

Once a false positive occurs, sometimes you are required to act immediately. In such a case, take temporary action to prioritize your application to keep running. A temporary measure can look like changing the action of a particular rule to COUNT mode or adding IP addresses to a whitelist.

Long-term action

The four main possible long-term actions are as follows.
Let’s take a look at them one at a time.

1. Adding an IP address to a whitelist permanently
Administrative tasks that use tools like CMS could cause false positives. If the rules work as intended and the requester can be deemed trustworthy, add the requester’s IP address to the whitelist.

2. Reevaluate the rules
If you are using string match conditions or regex match conditions, reevaluate the values and consider adjusting the rules themselves.

3. Create exclusion rules
Suppose a particular URI causes false positives due to a system’s structure. You can avoid it by creating exclusion rules with the condition that matches the particular URI (ex. URI that contains “import” like “/test/import/test”). Likewise, if you can narrow down the cause (i.e., specific information in the header), you can use that information as a condition and create rules.

4. Utilize COUNT mode
If you cannot narrow down the cause or if the number of rules you can add is limited and you cannot create new exclusion rules, consider using COUNT mode. You would not see an immediate effect by doing so, but you can review the requests that matched the rules later to utilize the information.

The effectiveness and plausibility of the possible actions listed above depend on the system and security policies you have in place, so it is essential to make a comprehensive decision.

Example of how to create exclusion rules

In this section, we are going to take a look at two patterns of exclusion rules’ implementation.

1. Using a condition to exclude

Let’s take a look at the way to exclude using paths. You need to add a condition to exclude using “doesn’t match the statement”. Conditions are evaluated by AND condition, so all conditions in the rule have to be true to match the rule. Thus, you want to match paths you don’t want to exclude in addition to the original rule.

Let’s say false positives occurred in an existing cross-site scripting rule provided for the body of a request. The website uses WordPress, and the false positives occurred under a specific path “/*/wp-admin/*”. In such a case, you can create a condition to exclude when a path “/wp-admin/” is included in the request.
The additional exclusion condition would be when a request does not match the path that includes “/wp-admin/”.

Refer to the blog post below for a detailed procedure of how to make the rule.
How to Block a Request that Contains a Specific String in URI with AWS WAF

You can also create an exclusion rule for IP addresses in the same manner by adding a certain IP address in an IP match condition and using “does not match”.

It might be easier to understand how conditions that do not match work by trying to create conditions that match requirements.

2. Excluding using rule order

In “Part 2 Relationship between Conditions and Filters” of this series, we created a whitelist rule. The purpose is to ignore the following rules if IP addresses match the whitelist. If you make a rule with action Allow when the request matches the condition, that request will not be checked by the following rules.

By using the behavior explained above, you can create a dedicated exclusion rule to check for SQL injection with the condition that matches a specific path and set action to Allow to avoid the consecutive cross-site scripting rule when checking requests.

3. Examples of exclusion patterns

Below are some of the commonly used exclusions patterns.

• Starts with a specific path
  Part of the request to filter on: URI
  Match type: Starts with
  Value to match: specific path
• Includes specific path
  Part of the request to filter on: URI
  Match type: Contains
  Value to match: specific path
• Access to specific file extension
  Part of the request to filter on: URI
  Match type: Ends with
  Value to match: specific file extension
• Access from a specific IP address
  IP addresses: specific IP address
• Access from a specific user identifier if the user identifier is included in the header
  Part of the request to filter on: specific header
  Match type: Exactly matches
  Value to match: user identifier

Conclusion

We hope the series has helped you understand the structure of AWS WAF better.
We believe that by reading this series, you’ll be able to utilize AWS WAF. Let’s manage safe and secure web applications.