The practice of Web application acquiring client IP and its security hidden danger

There are two ways that a Web program obtains a client IP, one is to obtain the IP directly from the source, and the other is to obtain it through the IP information in the HTTP header.

The former obtains the IP is the direct contact IP, both obtains is always the last ring IP, if the user uses the proxy, will not obtain the user real IP.

The latter obtains the IP is "proxy server" in the HTTP header plus information, to help identify or tag the IP path, or the client's original IP, but the HTTP header information is controllable, that is, can be forged.

In PHP, for example, PHP can get constant IPs via $_server and getenv as follows:

$_server[' REMOTE_ADDR '];

$_server[' Http_client_ip '];

$_server[' http_x_forwarded_for '];

Getenv ("Http_x_forwarded_for");

Getenv ("Http_client_ip");

Getenv ("REMOTE_ADDR");

Among them REMOTE_ADDR is the situation mentioned above 1,http_client_ip and Http_x_forwarded_for is the case two.

For a complete function of acquiring IP, it is more reasonable to obtain the IP of proxy server identity such as Http_x_forwarded_for and http_client_ip, if not exist, get the directly connected REMOTE_ADDR.

But the security risk is that the x_forwarded_for information is a field in the HTTP header that can be modified (forged) to any string. Suppose a business scenario is: The user's IP into the database, if first obtained the user forged IP string, injected SQL query statement, resulting in SQL Inject vulnerability.

So either get remote_addr directly, or filter the http_x_forwarded_for and so on (for example, filter by format, or use regular to shaving other characters other than ' point ' and ' number ')

The practice of Web application acquiring client IP and its security hidden danger