URI cannot be configured in Http Flood Protection

[hakkurt]

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] Since URI for HTTP Flood Protection cannot be directly configured, the probability of false positives are becoming high. Even it can be achieved by changing in Lambda Python Code, this makes solution complex to work in such adaptive manner;

Describe the feature you'd like A clear and concise description of what you want to happen. User can configure specific URIs for HttpFloodProtectionRateBasedRule

Additional context Add any other context or screenshots about the feature request here.

[aijunpeng]

Thanks for submitting the request. The HttpFloodProtectionRateBasedRule is a WAF service built-in rule and the solution simply deploys the rule as it is. Can you please provide more details regarding your use case? For example, what URIs do you use? How do you want to configure the URIs and what result do you expect?

[hakkurt]

Here is the use case : an attacker initiates a dictionary attack to login page (let's assume URI for login page is /accounts/login), he/she uses max 50 IPs in 5 minutes to by pass AWS WAF rate-based rule protection. We want to use HttpFloodProtectionRateBasedRule to prevent this attack but if we enable this rule with Request Threshold 50, every request to our web page will be counted and it will increase false positive rates. Only counting IPs which request login page (/accounts/login) will not block legitimate user traffic.

[aijunpeng]

Thanks for the information. Added this to our backlog for evaluation.

[diimpp]

This feature request sounds like an outside of security automation scope.

You can always create new rate based rule for your web acl with block or captcha actions and custom request match criteria.

Besides, you probably need "Account Takeover Prevention" https://aws.amazon.com/about-aws/whats-new/2022/02/aws-waf-fraud-control-login-credential-attacks/

[rakshb]

Upon further evaluation, we have decided not to add this feature in the immediate roadmap for the solution.