Home/ Questions/Q 820661
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T02:30:49+00:00

I’m pretty sure I remember reading –but cannot find back the links anymore– about

  • 0

I’m pretty sure I remember reading –but cannot find back the links anymore– about this: on some ISP (including at least one big ISP in the U.S.) it is possible to have a user’s GET and POST request appearing to come from different IPs.

(note that this is totally programming related, and I’ll give an example below)

I’m not talking about having your IP adress dynamically change between two requests.

I’m talking about this:

IP 1:  123.45.67.89
IP 2:  101.22.33.44

The same user makes a GET, then a POST, then a GET again, then a POST again and the servers see this:

- GET  from IP 1
- POST from IP 2
- GET  from IP 1
- POST from IP 2

So altough it’s the same user, the webserver sees different IPs for the GET and the POSTs.

Surely seen that HTTP is a stateless protocol this is perfectly legit right?

I’d like to find back the explanation as to how/why certain ISP have their networks configured such that this may happen.

I’m asking because someone asked me to implement the following IP filter and I’m pretty sure it is fundamentally broken code (breaking havoc for at least one major american ISP users).

Here’s a Java servlet filter that is supposed to protect against some attacks. The reasoning is that:

“For any session filter checks that IP address in the request is the same that was used when session was created. So in this case session ID could not be stolen for forming fake sessions.”

http://www.servletsuite.com/servlets/protectsessionsflt.htm

However I’m pretty sure this is inherently broken because there are ISPs where you may see GET and POST coming from different IPs.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Some ISPs (or university networks) operate transparent proxies which relay the request from the outgoing node that is under the least network load.

    It would also be possible to configure this on a local machine to use the NIC with the lowest load which could, again, result in this situation.

    You are correct that this is a valid state for HTTP and, although it should occur relatively infrequently, this is why validation of a user based on IP is not an appropriate determinate of identity.

    • 0