关于修改 HTTP 请求头问题

[lycos]

通过手动修改 HTTP 请求头的方式可以轻易骗过服务器，达到所谓的“伪造”客户端 IP 地址的目的，这招并非对于所有的网站有效（这取决于服务器获取 ClientIP 的方式）。
问题，如何避免访问网站的服务器端获取到本地真实 ip 呢？

[dallaslu]

不如挂代理。

[lycos]

@dallaslu 对于限制地址的网站 有没有什么方式让其识别为它地址范围内的呢？

[fxxkgw]

X-Forwarded-For

[lycos]

@fxxkgw 修改相应的 ip 后，但是百度搜出来的地址还是本地的。。如何能让百度搜出来的也是改过的 ip 呢？

[Keita1314]

这个只能用各种方法去测试服务端是通过哪种方式来判断的，然后去 hack ，但是永远也无法改变自己的真实 IP 地址，因为 TCP 连接是端到端的， 你要能接收到返回的信息，服务端始终需要知道你的真实 IP 。

[dallaslu]

醒醒吧。

[lycos]

@Keita1314 修改访问网站的 ip 地址后，服务器端同时检测到修改 ip 和本地的。想让其只检测到修改过的不检测本地的 除了 hack 级别的方式 没别的方式吗？

[Keita1314]

@lycos 服务端的规则是它定的，你只能利用他们的规则。如果你是服务端的设计者，可以知道本地和修改的 IP ，你肯定用本地的。

[lycos]

@Keita1314 恩 是的，没有突破服务端规则的方式吗？让它只识别修改的？

[imn1]

http 先要 ip-ip 握手，或者 ip-proxy-ip
然后才是 http 数据（ http 头数据就在这里）传输，如何伪造前面的握手 ip ？
改 http 只能测试服务器的程序的处理方式而已

你需要 tor

[lycos]

@imn1 专业！

[fising]

想要伪造请求来源，除非你要做的只是攻击，而不是抓内容。

[lycos]

@imn1 可否在详细的说下？一些很专业的知识目前还不太懂

[lycos]

@fising 不做攻击的。。

[TheCure]

就算你 fake 了一个请求,服务器怎么把包还给你呢?除非你不希望与服务器继续通信

当然了,这只是理论,有的结构比较复杂的是设计,比如服务器在调度器后面,这样他是拿不到用户真实的 ip,他需要检查 http 的 x forwarded for 字段,这个字段本来应该是调度器加上的,但是如果你已经加了这个字段,有可能欺骗调度器或者服务器

[lycos]

@callofmx 服务器端怎么设计我不知道 但是肯定的服务器现在能检测到本地的 。

[fising]

@lycos 了解 TCP 协议的话，就不会问这个问题了。

[lycos]

@fising 恩 没深入了解过。。

[imn1]

@lycos
我不专业，专业的没啥时间来回答你而已，例如 5L ，我只是比较闲
具体你可以去 wiki/google TCP 握手，或者看看 socket-http 程序
https://zh.wikipedia.org/wiki/%E4%BC%A0%E8%BE%93%E6%8E%A7%E5%88%B6%E5%8D%8F%E8%AE%AE 建立连接 一段

[mcfog]

参考 => http://symfony.com/doc/current/components/http_foundation/trusting_proxies.html

[Havee]

有些服务上了 cdn ，来路就基本都是那些 cdn 节点了
这个时候读 http head 省事

[Shieffan]

挂代理、 VPN



或者你修改本机 IP ，然后修改从本机 IP 到目标主机的所有路由设备的路由信息，以便它们能给你寻路，嗯，上帝模式。

[lycos]

@mcfog 服务端不是我控制的

[lycos]

@Shieffan 修改了本机 ip 不可行的

[gamexg]

tcp 协议设计之初就考虑到会有楼主这种伪装 ip 的攻击，设计时就封堵的差不多了。
后期一些容易操作的有问题的设计（例如源端路由）也都被纠正了。

另外一些就是运营商才能做到的了。

[Strikeactor]

乖乖挂代理吧，这事你不是运营商就别想了

[jin5354]

各种代理和 VPN 就是专门做这个的。憋寻思别的了

[lycos]

@jin5354 恩恩 这个问题问的有点白痴了。。 基本是不可能做到的

[lycos]

@Strikeactor 我当时是抱着等待高手的出现 看看高手有何高见的 。。现在看来是基本不可能了

[TheCure]

我来替 lz 总结一下

我是 lz
我的问题是白痴
你们回到不出我的问题,你们都不是高手

哈哈

[lycos]

@callofmx haha.... 大家回答的都很专业 只是我不专业..

[just1]

REMOTE_ADDR 是无法伪造的
当使用了 cdn ， REMOTE_ADDR 是 cdn 的 ip 。
但是 cdn 一般会传回一个客户的真实 ip 在 header 里。
比如 cf:HTTP_CF_CONNECTING_IP 就是 cdn 接受到的 remote_addr(也就是客户的真实 ip)。
所以隐藏是不太可能的。
但可以这样:穿透 cdn 找到源站 ip(虽然不容易，却也不是没办法)， hosts 指向。在每次请求头加入"HTTP_CF_CONNECTING_IP"，当然如果对方限制了仅 cdnip 可访问那就没办法了。
但是，这是根据程序逻辑来的，有的网站只获取 xff 并不校验，那修改 xff 就够了，同理 clientip 也是这样。

[Cloudee]

可以认为是不可能的

简单理解的话，就是服务器总是要知道你的 IP 来发回复的信息的，所以这个用于发送返回信息的 IP 服务器肯定有办法知道，如果你骗过这个的话，服务器的回复也回复不到你这里了

而因为 TCP 握手是要交互几次的，因此也不存在你把请求丢过去不管返回的情况

[mornlight]

楼主你可以逆向思维一下，如果可以仅在客户端伪造来源 ip 的话，那防火墙的 ip 过滤规则还有什么用？

按目前的协议设计，想要用假 ip 又正常通信，是不可能的。

所谓的改请求头的方式，只是针对非匿名代理或者 CDN 这种（会自动在 HTTP 头里标明请求的源 ip ）。很多网站后端取 ip 时会优先拿请求头里的源 ip 。

[mengzhuo]

@mornlight
@Cloudee

各种 sock_proxy 、 http_proxy 不就是改 IP 源么？

[Cloudee]

@mengzhuo 那是代理服务器做了中转。比如网站 B 和代理服务器 A ，你连 A ， A 连 B ，对于你来说你只跟 A 交互，对于 B 来说， A 才是自己的客户。
并不是你的数据包直接用 A 的 IP 发过去了，而你你把数据包发给 A ， A 把数据包原样用自己的 IP 发给 B 了。这个时候 B 回复是回复给 A 的，并不直接回复给你。

[lycos]

@Cloudee 所以这个过程是服务端既获取到 A 的 ip ， 又识别了数据包头的源 ip

[jasontse]

客户端 A: 你好我是客户端 B 。
服务器 A: 欢迎你，客户端 B 。
客户端 B: 莫名其妙，谁找我?
客户端 A: 尼玛! 服务器 A 不理我(其实招呼打到客户端 B 去了)。。。。

[mengzhuo]

@Cloudee

对啊，不就是这么个意思吗？

[Cloudee]

@mengzhuo 但是你要有可用的代理，并且代理是知道你的 ip 的，因此你还要代理不通过 http 头泄露你的真实 ip

[jugelizi]

好比你让儿子去邻居老王家借点盐，儿子刚出名你就把门给封了，不想让他回来
这个，，，当然也是可以的

[iyangyuan]

这只能用代理，否则怎么通信？

[simpx]

你给对方寄了一个快递，盒子上写了你的地址 A ，盒子里附带了一封信，写着『我家住在地址 B 』，对方给你回寄东西的时候，如果地址 A 是错的，那你就收不到东西了。但对方在登记你的信息的时候，有时候会傻傻的用你盒子里的信里声明的地址 B 。

你给对方发了一个 HTTP 请求， ip 协议里写了你的 ip 地址 A ， HTTP 请求头里伪造了 ip 地址 B 。服务端始终回复数据给地址 A ，伪造地址 A 会导致你收不到服务端响应。但很多 web server 在记录你的 ip 信息时，会省事使用 HTTP 请求头里的 ip 地址 B 。

[simpx]

@simpx 想要对方不知道你真实地址，在现实的例子中，你可以用『菜鸟驿站』，也就是代理

[msg7086]

#39 @mengzhuo 不是改源 IP ，而是重新定义了连接。
本来网络连接是从你到服务器，现在变成了从代理到服务器。
源 IP 还是连接的这一头，也就是代理的 IP 。
这不是伪造源 IP ，因为你的数据的确就是从源 IP ，也就是代理，发出去的。

[mengzhuo]

@Cloudee
@msg7086

你们说的都是对客户端来讲的，对服务器来说，源 IP 不一样了嘛，这样不就是 OP 的原始诉求了么？
其实常见的生活中 NAT 也是一种“改源 IP ”的方法。
当然，要是能控制 AS ， L3 级的更改也不是事了。