Open chrishow opened 2 weeks ago
Further to this, instead of using the custom_server_parameter
, the user should use the "Trusted Proxies" laravel feature to handle remote IPs.
I have tested adding a trusted proxy and the remote IP is correctly rewritten and laravel-ip-middleware
uses it correctly without needing a custom_server_parameter
config key.
Hi!
Great middleware, but there's a usage issue which might not be immediately obvious to users. Perhaps the documentation ought to mention it?
It is this:
If your server was behind a Cloudflare proxy, you might set the config option as is mentioned in the code comment:
'custom_server_parameter' => 'HTTP_CF_CONNECTING_IP'
However, unlike 'REMOTE_ADDR', which is passed up directly from the network stack, the $SERVER['HTTP*'] values are simply generated by PHP from the request headers.
This means that provided an attacker knew:
The could send request to the actual server IP address with a 'CF_CONNECTING_IP' header containing an ip address on the whitelist. PHP would then add a corresponding HTTP_CF_CONNECTING_IP entry in the $_SERVER superglobal, and the middleware would accept the request.
I don't think it's within the scope of this middleware to do anything to mitigate this attack vector, just that perhaps the documentation should mention the risk.
I will provide a PR with amended documentation if you like.