A rate limiter that keyed on the visitor’s IP could be dodged by sending a fake forwarded-IP header with a different value on every request, so the limit never triggered.
A Rate Limiter Must Trust the Right End of the Forwarded-IP Header
Field Note #329
⚡ Quick Fix (TL;DR)
The Culprit: The forwarded-IP header is a list. A client can write anything at the left end, and the CDN appends the real visitor address at the right end. Using the first (left) entry, or letting the framework treat every entry as trusted, means the key is attacker-controlled.
The Fix: Look at what your own site actually receives (a temporary diagnostic showing the raw header and the connection address), then key on the entry the trusted proxy wrote: the last one when there is one trusted hop. Prove it with a forged-header test against your own site: send 31 requests that each claim a different IP and confirm the 31st is still refused. Give each route its own counter, and treat IPv6 by its /64 prefix.
Was this helpful? Thanks for the feedback!
Tagged in :