- [Instructor] AWS WAF now supports
evaluating multiple headers in the HTTP request
without the need to specify each header individually
in the AWS WAF rules.
You can also use this new feature to inspect all cookies
in the HTTP request
without the need to specify each cookie in the WAF rules.
This capability helps you protect your applications
or API endpoints from attacks that try
to exploit a custom header or cookie
or a common header for which you may not have created
a WAF rule.
You can also limit the scope
of inspection to only included or excluded headers
and inspect only the keys or only the values
for the headers or cookies you want to inspect.
For HTTP requests that may include more headers
than WAF can inspect,
you can provide oversize handling instructions
when you define your rule statement.
Oversize handling tells WAF what to do with a web request
when the number
or size of request headers is over the limits.
With oversized handling,
you can choose whether to continue inspection
or skip inspection and mark the request as matching
or not matching the WAF rule.
There is no additional cost
for matching against all headers or cookie details
but standard service charges for AWS WAF still apply.
These features are available in all AWS WAF regions
and for each supported service
including Amazon CloudFront, Application Load Balancer,
Amazon API Gateway, and AWS AppSync.
For a full list of request component options
that are supported, see the AWS WAF Developer Guide.
Attacks may look different than inspected
and they don't always succeed.
Often, threat actors are guessing how
to compromise a request.
Requests should be considered malicious
if there is malicious content in the header or cookies,
even if the attack fails.
When making custom rules in AWS WAF,
you can now inspect more than a single header
or cookie in a single rule.
This allows you to identify a threat
even if you don't know exactly what you're looking for.
Because there are limits on the size
or the numbers of headers or cookies,
AWS WAF provides rule choices on how to handle a request
if the content exceeds the limit thresholds.
Now we're going to look at this new feature in action.
In the demo, we will send requests to a live system.
You will see how to configure new rules in AWS WAF
to block the requests when they contain
objectionable header content.
First, let's have a look at the system architecture.
Here we have an Application Load Balancer
configured to route requests to a Lambda function.
For demonstration purposes,
the Lambda function will simply respond back
to the requesting application
with the header sent in the request.
This will allow us to show when a request
was successfully routed
and see the content of the header sent.
AWS WAF will inspect the request before routing.
Any request blocked will send an error response back
to the requesting application.
For the beginning of the demonstration,
we will send through a request
with several headers containing SQL.
SQL code in headers are indicators of a malicious request.
I'll also include an identifiable body
so that we can see that the data sent is the data returned.
Because there are no WAF rules in place,
you can see that the request went through
and the Lambda function sent back the contents,
including all the headers.
Note that several headers are guesses
at possible server side variables
where my SQL injection could be executed.
As you can see, I have many versions
of possible user ID fields, some passwords, and item IDs.
Now let's look at the WAF console.
For this demo, I have a web ACL attached to my ALB,
but there are no rules.
Let's go ahead and create a rule
that will block any SQL showing up in the request headers.
First we'll click on Add Rules,
then we'll select Add My Own Rules and Rule Groups.
This is the Add Rule form.
This makes it easy to create your own custom rule
to block the kinds of headers we just saw.
First, we'll add a name.
Then we'll tell AWS WAF what to inspect.
You can see we have many options
but we want to inspect all headers.
We have the option here to inspect all parts of the header
or we can specify to look at just the key
or just the value.
In the Content to Inspect section,
you can choose to allow WAF to inspect all headers
or just a subset.
For this demo, we'll go ahead and look at them all.
For match type, we want to match on any header
that contains a SQL injection.
Oversize Handling is where we would tell WAF what to do
with requests that exceed the size or count limits.
We can choose to inspect just what's within these limits
or we can declare the request a match or not a match.
For now, we're going to select Continue.
The rule will inspect what it can,
ignoring any content outside the size limits.
The Then section tells WAF what to do
in case of a rule match.
We will leave the action as block.
In the custom response,
I want to specify a 403 response code.
For this demo, I will also return a custom body.
This is not always necessary, but for the demo,
it will give us an easy indicator
that the rule is working as expected.
Now that we're done, we'll go ahead and click Add Rule.
On this page, we set the rule priority.
Since it is the only rule,
we can go ahead and just hit save.
Now that the rule is applied,
we can go back to our demo application and see the results.
Now, back to the application.
We will send the request again.
I'll change the request body so
that we can see that the data sent is the data returned.
The rule worked.
It correctly identified the SQL code in the headers
and returned our custom body.
But what about an oversize request?
I'll add 200 headers to push the malicious headers
to the bottom of the list.
With the current rule,
the malicious headers will be invisible.
So when we execute this request,
the SQL code escapes detection
As you can see, the rule failed to block this request
because the number of headers was too large
and the malicious headers weren't matched to the rule.
So let's go back to the AWS WAF console.
To change our rule,
we're going to select it
and then click Edit.
Now back in the rule editor,
we'll scroll down to the Oversize Handling section
and change the selection.
We're going to select Match,
because for this application, any request with more
than 200 headers would be trying to hide malicious content.
Now we'll save.
And save.
And now we'll go back to the application
and see how that works.
With our rule now changed to assume a match if the number
of headers exceeds the limit,
we'll execute the request again with the 200 extra headers.
And now the request has been blocked.
When making your own rules,
you will have to assess what kind of oversize handling
would be best for your application.
To learn more about multi-header
and multi-cookie handling in AWS WAF,
visit the Developer Guide
and the feature announcement.
Both of these links can be found in the description
of this video.
Thank you for taking the time to watch.
If this content was helpful, please click the like icon.
Have a great day.