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:
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_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.
This is the biggest “catch all” category of AWS WAF, just look at all the rules with it:
If you are a flunky like me, the CrossSiteScripting_* rules are what popped out to you first.
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: https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-list.html