Is it possible that REMOTE_ADDR could be blank?

Question

As far as I'm aware, the webserver (Apache/Nginx) provides the ($_SERVER['REMOTE_ADDR']) based on the claimed location of the requesting user agent. So I understand they can be lying, but is it possible that this value could be blank? Would the network interface or webserver even accept a request without a correctly formed IP?

http://php.net/manual/en/reserved.variables.server.php

Answer 1

It is theoretically possible, as the matter is up to the http server or at least the corresponding PHP SAPI.

In practice, I haven't encountered such a situation, except with the CLI SAPI.

EDIT: For Apache, it would seem this is always set, as ap_add_common_vars always adds it to the table that ends up being read by the Apache module PHP SAPI (disclaimer: I have very limited knowledge of Apache internals).

If using PHP in a CGI environment, the specification in RFC 3875 seems to guarantee the existence of this variable:

4.1.8.  REMOTE_ADDR

   The REMOTE_ADDR variable MUST be set to the network address of the
   client sending the request to the server.

Answer 2

Yes. I currently see values of "unknown" in my logs of Apache-behind-Nginx, for what looks like a normal request/response sequence in the logs. I believe this is possible because mod_extract_forwarded is modifying the request to reset REMOTE_ADDR based on data in the X-Forwarded-For header. So, the original REMOTE_ADDR value was likely valid, but as part of passing through our reverse proxy and Apache, REMOTE_ADDR appears invalid by the time it arrives at the application.

If you have installed Perl's libwww-perl, you can test this situation like this (changing example.com to be your own domain or application):

HEAD -H 'X-Forwarded-For: ' -sSe http://www.example.com/
HEAD -H 'X-Forwarded-For: HIMOM' -sSe http://www.example.com/
HEAD -H 'X-Forwarded-For: <iframe src=http://example.com>' -sSe http://www.example.com/

( You can also use any other tool that allows you to handcraft HTTP requests with custom request headers. )

Now, go check your access logs to see what values they logged, and check your applications to see how they handled the bad input. `