AWS WAF — Know Your Enemy

How many times have you been testing out a new program on Hackerone just to see they use AWS WAF and then decide to move on to an easier target?

Low hanging fruit gatherers, like myself, can be discouraged to see a WAF protecting all the poorly coded endpoints that promise to pay off my mortgage.


When you see AWS WAF on your target, do not assume that it’s been properly configured!
The worst thing you can do as security researcher/bug bounty is assume a WAF is properly configured, but you cannot find shortfalls if the WAF if you do not know what they could possibly be.

Lets break down the AWS WAF into some parts so you have more to test.

AWS WAF comes out of the box with these default parent rules:

Default AWS WAF Rules

Each parent rule comes with its own set of child rules on what and where to block traffic.


Viewing a rules associated with AWSManagedRulesSQLiRuleSet below can you tell which one is disabled?

SQLi Rules

SQLi_COOKIE is in the “Override rules action” position and thus disabled.
Meaning there is a great SQLi protection across all HTTP request bodies/URL path/URL parameters etc, but nothing protecting cookies from injection.

Gist table auto-insert is a lie


This is the biggest “catch all” category of AWS WAF, just look at all the rules with it:

Commonest Rules

If you are a flunky like me, the CrossSiteScripting_* rules are what popped out to you first.

Take Away

Just because you see AWS WAF errors for your URL payload, do NOT assume the same WAF protects the Body.
Be patient of thorough in your testing

Documentation of all rules:

Reformed Baptist Son Of A Shepard

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store