来自同一台机器的 GET 和 POST 请求可以来自不同的 IP 吗?

发布于 2024-09-03 14:12:43 字数 1031 浏览 1 评论 0原文

我很确定我记得读过——但再也找不到链接了——关于这一点:在某些 ISP(包括美国至少一家大型 ISP)上,可能会出现用户的 GET 和 POST 请求来自不同的IP。

(请注意,这完全与编程相关,我将在下面给出一个示例)

不是谈论让您的 IP 地址在两个请求之间动态更改。

我说的是这个:

IP 1:  123.45.67.89
IP 2:  101.22.33.44

同一个用户发出一个 GET,然后发出一个 POST,然后再次发出 GET,然后再次发出 POST,服务器会看到这一点:

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

所以尽管它是相同的 em> 用户,网络服务器会看到 GET 和 POST 的不同 IP。

当然知道 HTTP 是一个无状态协议,这是完全合法的,对吗?

我想找到有关某些 ISP 如何/为何将其网络配置为导致这种情况发生的解释。

我这么问是因为有人要求我实现以下 IP 过滤器,而且我很确定它从根本上来说是损坏的代码(对至少一个主要的美国 ISP 用户造成了严重破坏)。

这是一个 Java servlet 过滤器,旨在防止某些攻击。原因是:

对于任何会话过滤器都会检查请求中的 IP 地址是否与创建会话时使用的 IP 地址相同。因此在这种情况下,会话 ID 无法被窃取以形成虚假会话。”

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

但是我我非常确定这本质上是有问题的,因为在某些 ISP 中您可能会看到来自不同 IP 的 GET 和 POST。

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.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

一曲琵琶半遮面シ 2024-09-10 14:12:43

一些 ISP(或大学网络)运行透明代理,中继来自网络负载最小的传出节点的请求。

也可以在本地计算机上进行配置,以使用负载最低的 NIC,这可能会再次导致这种情况。

您是正确的,这是 HTTP 的有效状态,尽管它发生的频率相对较低,但这就是为什么基于 IP 的用户验证不是适当的身份确定的原因。

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.

毅然前行 2024-09-10 14:12:43

对于 Web 服务器来说,看到这一点意味着最终用户位于某种代理/网关后面。正如你所说,考虑到 HTTP 是无状态的,它是完全有效的,但我想这会很不寻常。据我所知,大多数 ISP 都会为家庭用户分配一个真实的、未转换的 IP(尽管通常是动态的)。

当然,对于企业/机构网络,他们可以做任何事情。负载平衡可能意味着请求来自不同的 IP,并且有时请求类型可能会被分配到不同的网关(尽管我很想知道为什么,因为 N_GET >> N_POST)。

For a web server to be seeing this implies that the end user is behind some kind of proxy/gateway. As you say it's perfectly valid given that HTTP is stateless, but I imagine would be unusual. As far as I am aware most ISPs assign home users a real, non-translated IP (albeit usually dynamic).

Of course for corporate/institutional networks they could be doing anything. load balancing could mean that requests come from different IPs, and maybe sometimes request types get farmed out to different gateways (altho I'd be interested to know why, given that N_GET >> N_POST).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文