How to Prevent access requests from forging ip addresses

For example, if a piece of code I tested accesses an IP address query service, we can see that any forged IP address can be used! In a PHP project currently in progress, you need to verify whether the user's IP address is in the authorization scope. Is there any way to prevent the user from forging the IP address? Or, can you provide...

For example, if a piece of code I tested accesses an IP address query service, we can see that any forged IP address can be used!

In a PHP project currently in progress, you need to verify whether the user's IP address is in the authorization scope. Is there any way to prevent the user from forging the IP address?

Or is it possible to provide other ideas?

Supplement: the actual scenario is rest call. Both the called and called ends are servers ~

Reply content:

For example, if a piece of code I tested accesses an IP address query service, we can see that any forged IP address can be used!

In a PHP project currently in progress, you need to verify whether the user's IP address is in the authorization scope. Is there any way to prevent the user from forging the IP address?

Or is it possible to provide other ideas?

Supplement: the actual scenario is rest call. Both the called and called ends are servers ~

Provide several ideas:

1. If it is a LAN environment, we recommend that you restrict IP addresses from the system or even the router.
2. If it is public, the forged IP address will not be able to receive your Response, that is, this Response will be sent to the forged IP address. Therefore, it is meaningless to forge an IP address unless it is a flood attack on you.

Besides, the solution you commented on is actually a verification method. I think this method is no different from symmetric encryption, of course, the cost of symmetric encryption is much lower than the handshake method you mentioned.

In short, the IP address is restricted for access, but for data security, encryption and authentication are still required. symmetric encryption is a good method (adding time and other elements to symmetric encryption, high Security ).

REMOTE_ADDR is not so easy to forge.
See
Can $ _ SERVER ['remote _ ADDR '] be trusted?
Http://stackoverflow.com/questions/58...

$ _ SERVER starting with "HTTP _" is easy to forge.

It is quite easy to judge the service segment. In fact, the following code also determines whether to use proxy.

Conclusion: It is recommended that the Service segment be $ _ SERVER ['remote _ ADDR '].

------------------------ Small episode ---------------------
Recently, I helped people study discuz's xplus voting system.

function _get_client_ip() {$clientip = '';if(getenv('HTTP_CLIENT_IP') && strcasecmp(getenv('HTTP_CLIENT_IP'), 'unknown')) {$clientip = getenv('HTTP_CLIENT_IP');} elseif(getenv('HTTP_X_FORWARDED_FOR') && strcasecmp(getenv('HTTP_X_FORWARDED_FOR'), 'unknown')) {$clientip = getenv('HTTP_X_FORWARDED_FOR');} elseif(getenv('REMOTE_ADDR') && strcasecmp(getenv('REMOTE_ADDR'), 'unknown')) {$clientip = getenv('REMOTE_ADDR');} elseif(isset($_SERVER['REMOTE_ADDR']) && $_SERVER['REMOTE_ADDR'] && strcasecmp($_SERVER['REMOTE_ADDR'], 'unknown')) {$clientip = $_SERVER['REMOTE_ADDR'];}preg_match("/[\d\.]{7,15}/", $clientip, $clientipmatches);$clientip = $clientipmatches[0] ? $clientipmatches[0] : 'unknown';return $clientip;}

Haha...

The X-FORWARDED-FOR is the Client IP that the proxy server provides through HTTP Headers. The proxy server can forge any IP address.

To prevent forgery, do not read this IP address (and tell the user not to use HTTP Proxy ).

For PHP, $ _ SERVER ['remote _ ADDR '] is the IP address directly connected to your SERVER. You can use this IP address.

I also tried this, not only the X-FORWARDED-FOR, can also forge CLIENT_IP request header, to see how your script to get the key of the Request Header, as if there is no way to forge REMOTE_ADDR, you can take this, in PHP, it is $ _ SERVER ['remote _ ADDR ']. I don't know if there will be null values.

It is almost impossible to completely avoid it. The transparent and anonymous http proxy can detect http headers, but what about socks proxy or self-implemented port forwarding?
Now we can think of maintaining a huge library, adding all the ip addresses that can be collected as proxies, and comparing the advanced databases before users access the database. However, this disadvantage is also great. First, the access speed of the database is too high, which will slow down and affect the efficiency. Second, some ip addresses may only be proxies for the moment, such as bots, which may return to normal, for example, if the ip address dynamically assigned by the carrier is used as an agent today, it may not be a proxy if it is assigned to you tomorrow. If there is no good detection and removal mechanism, it is very likely that it will be killed by mistake; third, the database cannot collect all the proxies. It is only possible to collect some public proxies on the Internet. Private proxies are difficult to collect and the proxies outside the database cannot avoid access.
However, some companies are maintaining such libraries to provide external services through APIS.