Heh, nice catch.
I have not stumbled upon a similar thing but definately will keep in mind.
Thank you for sharing !
This is an error of a WP security plugin i guess (so is the 418 error, i think it's of wp better security?).
I think (i may be wrong), this could happen with bad plugins that use the wrong headers to retrieve the real client ip, there might have many WP plugins (and other cms) out there that don't allow the user to specify which header to search for the real ip, and that try to get it from all possible headers.. This is so wrong!
I think that's always better to do it through the webserver instead of using those broken plugins, in nginx you can specify the header to look for the real ip, in apache rpaf too.
That's a pretty wildly bad mis-configuration. There's no reason the WAF should have to explicitly trust itself, and moreover, a cache server should never be treated as a trusted source, in any event. And there's no good reason to trust the XFF header (of any name) to enable a bypass.
Even when counseling customers using large CDN's, the only way to ensure some integrity of an XFF header is to restrict the network-level permitted sources to the CDN IP's, and then use the XFF for more advanced correlation and mitigation (like IP reputation or geolocation).
Since this is your environment, can you tell us if the WAF in the test was used in a proxy configuration? This may be of no consequence for how the WAF determines how to block the source, but my question is whether the WAF will use the X-originating-IP to actually route traffic in any instance, or if this is decoupled with the TCP/IP info for the actual routing of the packets involved. I am wondering if a WAF as a proxy configuration would handle these blocks differently than an inline or promiscuous installation topology, or if this is of no real consequence?
Or maybe I am looking at this all wrong :)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.