【问题标题】:Web infrastructure should reset "x-forwarded-*" headers?Web 基础设施应该重置“x-forwarded-*”标头吗?
【发布时间】:2018-03-19 01:56:02
【问题描述】:

给定一个网络基础设施,具有:

WEB --> HTTP 代理 --> NGINX --> PHP

我们使用 Php 中的 "X-forwarded-{for,host} 来获取真实的 IP 和主机。但有时,我们得到了错误的值,我发现可以像这样设置这些字段:

curl -sL http://www.toto.com -H "X-Forwarded-For: 1.96.0.1"

作为开发人员,我无权访问 haproxy/nginx 配置和我们的基础设施。伙计们说这是开发人员的错。

因此我的问题是,前端 HTTP 代理应在将查询代理到应用服务器之前删除用户“X-forwarded”字段?

【问题讨论】:

  • 这是有问题的,因为如果连接本身来自另一个代理,并且您删除了这些标头,那么您就会丢失客户端地址并获得代理地址。因此,您也不能信任标头,因为它很容易被欺骗,所以您的电话
  • 我建议仅删除来自网络的标头,而不是来自内部流量。我们有特定的网络流量入口点(用于管理 SSL)。

标签: http nginx haproxy x-forwarded-for


【解决方案1】:

错误是假设X-Forwarded-For 中最左边的值是客户端地址。这不是它的预期工作方式。

X-Forwarded-For 的工作原理是将传入连接的地址附加到传入标头值的右侧(如果存在)。

正确的解决方案是让应用程序从右侧开始读取,在向左移动时消除可信地址,然后停止。

最右边的不受信任地址是您要查找的地址。

X-Forwarded-For: 192.168.1.5, 203.0.113.5, 10.0.0.5

假设 10.0.0.5 是代理。 Nginx 添加了这个地址,因为连接来自代理。您知道此地址并相信它始终会附加它所看到的客户地址,因此您将其从列表中删除。它不是浏览器。您知道,凭借您对这台机器的信任,左边的下一个地址是真实且正确的,并且是由代理添加的。

删除 10.0.0.5 后,您会发现 203.0.113.5 现在是最右边的地址。因为您刚刚删除了一个受信任的地址,所以您知道 203.0.113.5 是正确的,但您不认识,因此无法信任该地址左侧的任何进一步信息。如果 203.0.113.5 是 Web 代理,属于外部组织,那么左边的下一个地址 192.168.1.5,可能是该设备后面的浏览器地址,或者可能是伪造的.最终,没关系,因为最右边的不受信任的地址,203.0.113.5 就是你想要的地址。这是连接到您的堆栈的外部机器的地址。

您可能想要记录或以其他方式保留更左侧的值,但在删除任何受信任的地址后,除了最右边的剩余地址之外,您无法做出任何决定,因为这是您唯一可以做的相信。

重要的是,您必须在最右边的不受信任的设备地址处停止进一步处理,因为如果受信任的地址出现在该点的左侧,那么它就是伪造的。

【讨论】:

  • 我认为他们(基础设施人员)错误配置了 Nginx/HAProxy,因为我们没有(从应用程序)看到一个列表,而是一个 IP,可以通过设置 x-forwarded-for 标头轻松覆盖.所以,应用程序必须知道代理 IP:/ 我不喜欢这种方法,我更喜欢保持应用程序的基础设施不可知,或者这可能是一个好习惯?
  • 如果代理可以通过在请求上伪造一个标头来愚弄,他们肯定而且毫无疑问做错了什么。回复:不可知论,这也很好,但这意味着只有堆栈中最外层的服务应该添加X-Forwarded-For 来识别它的客户端,并且任何内部中间机器都不应该做任何事情......这反过来意味着你失去了有价值的故障排除信息关于请求的内部路由。您的应用不需要了解 10.0.0.5 是专门的代理,而是 10.0.0.0/16 是受信任的子网。
  • HAProxy 支持 option forwardfor 的 if-none 参数,以在已经存在的情况下禁止代理添加标头,但这应该永远用于面向外部的机器。从根本上说这是错误的。
猜你喜欢
  • 1970-01-01
  • 2019-03-09
  • 2010-09-18
  • 1970-01-01
  • 2020-05-22
  • 1970-01-01
  • 1970-01-01
  • 2020-01-25
  • 2023-03-15
相关资源
最近更新 更多