php / ajax REMOTE_ADDR set to IP of bogus network adapter

6
votes

today I came a across a pretty strange behaviour of an php based application of mine. In a certain part of the system there's an UI making use of AJAX-calls to fill list boxes with content from the backend.

Now, the AJAX listener performs a security check on all incoming requests, making sure that only valid client IPs get responses. The valid IP are stored in the backend too.

To get the client's IP I used plain old

$_SERVER['REMOTE_ADDR']

which works out for most of the clients. Today I ran into an installation where remote_addr contained the IP of an network adapter which was'nt that one which performed the actual communication for my application.

Googling around agve me Roshan's Blog entry on the topuic:

function getRealIpAddr()
{
    if (!empty($_SERVER['HTTP_CLIENT_IP']))   //check ip from share internet
    {
      $ip=$_SERVER['HTTP_CLIENT_IP'];
    }
    elseif (!empty($_SERVER['HTTP_X_FORWARDED_FOR']))//check ip is pass from prxy
    {
      $ip=$_SERVER['HTTP_X_FORWARDED_FOR'];
    }
    else
    {
      $ip=$_SERVER['REMOTE_ADDR'];
    }
    return $ip;
}

Sadly the problem persists.

Did anybody ever stumble into this sort of problem (actually I don't think that I discovered a completly new issue ^^) and has an idea for me how to fix this?

EDIT:

I'm on

  • PHP Version 5.2.9-1
  • Apache/2.2.9 (Win32)

The communication is done via a regular LAN card. Now the actuall client has several devices more. VMNet adapters and such.

I'm wondering how a client configuration can 'disturb' a web server that much...

TIA

K

1
phpajax
can you put in some details here regarding the adopters and the server running the application.. i mean what IPs do they hold. – Sabeen Malik
so example scenario might look like this on client end: eth0 - 10.0.0.1 eth1 - 10.1.1.1 then on server u have 10.1.1.2 and when the request goes through from client instead of 10.1.1.1 it shows 10.0.0.1 ? – Sabeen Malik
correct, eth1 does the job, so i want to have 10.1.1.1 in remote_addr. – KB22
That is really weird , i havent seen a behavior like that , i think this might have something to do with the client network config. If there is routing in place, you might want to check the gateway configuration etc, maybe shut down all connections and bring back one by one and see where the problem starts to happen and then check that specific network adopters config .. just my 2 cents. If both are on seperate subnets than this shouldnt be happening at all, atleast i cant think of a logical reason for it to happen. – Sabeen Malik

1 Answers

5
votes

Unfortunately, you have to take all IP information with a grain of salt.

IP addresses are gathered during the request by taking the packet and request information into account. Sadly, this information can easily be spoofed or even be incorrect (based on a large number of network probabilities) and should not be used for anything more than vanity purposes.