Waf Charm

Blog

AWS WAF

Custom Header and Response Features are Now Available in AWS WAF

【Table of contents】

  1. Introduction
  2. Custom Header Functions
  3. Custom Response Functions
  4. How to Set Up
  5. WafCharm Support
  6. Possible Use Cases
  7. Conclusion

1. Introduction

On March 29, 2021, two customization features were released in AWS WAF

  1. adding a custom header when passing through the AWS WAF
  2. customizing the response when BLOCK-ed

Let's take a look at what each of these features are.

If you want to know the merits, please go to section 6, “Possible Use Cases”.

2. Custom Header Function

This is a function to add a custom header when a request passes through the AWS WAF with ALLOW or COUNT. It is expected to be used for subsequent processing based on the inserted header as a flag for analysis.

The custom request header name will be prefixed with "x-amzn-waf-" to avoid confusion with headers already in the request. For example, if you want to add a custom header named "test", it will be "x-amzn-waf-test".

If the same custom header exists in the original request, it will be overwritten by AWS WAF.

If there are multiple rules that give the same custom header, and multiple rules are matched, they will be checked in order of priority, and the content of the rule that finally matches (the rule with the lowest priority) will be configured.

If two rules are matched, COUNT and ALLOW, and each is given a different custom header, then both will be given.

In a simple example, if all rules are matched in the following rule order, "count-test:2" and "allow-test:3" is set at header in the end.

Rule 1 (COUNT) -> "count-test:1" is added
Rule 2 (COUNT) -> "count-test:2" is added
Rule 3 (ALLOW) -> "allow-test:3" is added

The custom header function is not available for COUNT by override action in the rule group.

3. Custom response function

This function allows you to configure the response when BLOCK-ed by AWS WAF.

By default, when a BLOCK-ed, the HTTP status code is 403, but it is now possible to replace the status code, header, and static page.

The response settings can also be customized for CloudFront and API Gateway, but note that the settings for AWS WAF take precedence.

4. How to Set Up

Custom header function

In the "Action" section of the rule creation, if "Allow , Count" is selected, the "Custom request" setting can be configured.

By selecting "Add new custom header", you can set the Key and Value.
You can register more than one.

If you check the JSON, you will see that the Action used to be only "Allow , Count", but now it is added as CustomRequestHandling.

 

 "Action": {
   "Count": {
     "CustomRequestHandling": {
       "InsertHeaders": [
         {
           "Name": "test2",
           "Value": "2"
         }
       ]
     }
   }
 }

Custom response function
If "Block" is selected in the "Action" section of the rule creation, the "Custom response" setting can be configured.
Check the "Enable" checkbox to open the input field.

Set the status code you want to use in "Response code".
By selecting "Add new custom header", you can set the Key and Value.
You can register multiple headers.
Select "Create a custom response body" in the "response body" section to create a static page. You can also select the content you have registered in advance (the part labeled "test" in the image below).

To register the ACL in advance, select the target ACL, select "Custom response bodies", and click "Create".

Enter the necessary information in the edit screen.

If you check the JSON, you will see that additional information has been added in the "Block" with a key called CustomResponse.

 

 "Action": {
   "Block": {
     "CustomResponse": {
       "ResponseCode": 404,
       "CustomResponseBodyKey": "test",
       "ResponseHeaders": [
         {
           "Name": "test",
           "Value": "1"
         }
       ]
     }
   }
 }

The contents of "Custom response bodies" will be the information associated with the ACL, and when the ACL information is displayed in JSON, the following information has been added when the ACL information is displayed in JSON. It is referenced from the rule with the key "test".

 

 "CustomResponseBodies": {
   "test": {
     "ContentType": "TEXT_PLAIN",
     "Content": "test"
   }
 }

In the case of rule groups, "Custom response bodies" should be attached to the rule group itself, and the content of "CustomResponse" should be set in the "Action" field of each rule under the rule group.

5. Support in WafCharm

We don’t currently have any plan to implement features that support the two functions in WafCharm.

For example, if the custom response function is set to indicate that a WAF BLOCK has been performed, the difference in the response will give the attacker some information that can be guessed, which may be a risk from a security perspective.

6. Possible use cases

By using the custom header function as a flag, as described in the official information, it is possible to identify accesses that have passed through the WAF and accesses that have not passed through the WAF in the access log at the later stage.

The custom response function can be used to check the effectiveness of the WAF in development and validation environments. For example, you can check whether the 403 response is caused by WAF or not.

7. Conclusion

This function has limited use cases. The custom response function is not recommended for service provider sites that are accessed by an unspecified number of people, as it gives an attacker not small amount of information. For environments with limited access such as development environments, you may want to consider using the custom response feature since it allows you to know the status of the WAF from the website access log at the back end of the WAF.