在 http 头中有一个字段:X-Forwarded-For,该字段是一个 HTTP 扩展头部。HTTP/1.1(RFC 2616)协议并没有对它的定义,它最开始是由 Squid 缓存代理软件引入,用来表示 HTTP 请求端真实 IP。如今它已经成为事实上的标准,被各大 HTTP 代理、负载均衡等转发服务广泛使用,并被写入 RFC 7239(Forwarded HTTP Extension)标准之中。

假设一个场景,你的网站使用了 CDN 加速, CDN 会隐藏掉你源站的真实 IP, 当请求到达时,会先请求到 CDN 边缘节点,而后转发到源站,此时你可以把 CDN 当做是一个代理服务器,事实上,它也确实是一个代理服务器。

字段介绍

X-Forwarded-For 请求头格式非常简单,就这样:

X-Forwarded-For: client, proxy1, proxy2

其内容由英文逗号 + 空格隔开的多个部分组成,最开始的是离服务端最远的设备 IP,然后是每一级代理设备的 IP。

如果一个 HTTP 请求到达服务器之前,经过了三个代理 Proxy1、Proxy2、Proxy3,IP 分别为 IP1、IP2、IP3,用户真实 IP 为 IP0,服务端最终会收到以下信息:

X-Forwarded-For: IP0, IP1, IP2

伪造 IP

现在很多的网站都会使用代理或 CDN(CDN 本质上也是代理服务器),当启用了代理服务器,后端服务器就无法直接获取客户端的真实 IP 地址了,比如 又拍云 CDN 回源的时候默认传到源站的是 IP 是中转节点的 IP,又拍云会提供2个http 字段 X-Real-IP 和 X-Forwarded-For 来传递真实的客户的 IP,这样即使走 CDN 源站也能通过这2个字段来获取真实的 IP 地址,详见文档

但是 X-Forwarded-For 是可以非常轻易的伪造的,和伪造 referer 一样简单。

比如使用又拍云的 CDN 加速后,如果想拿到真实 IP 只能用又拍提供的获取真实 IP 文档所描述的内容来获取,但是客户的这样请求:

curl -X GET https://www.fangwenjun.com/post/54079.html -H "X-Forwarded-For:1.1.1.1" 

服务端日志格式如下:

log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                                     '"$status" $body_bytes_sent "$http_referer" '
                                     '"$http_user_agent" "$http_x_forwarded_for" '
                                     '"$gzip_ratio" $request_time $bytes_sent $request_length';

获得的日志内容是

183.131.24.75 - - [13/Dec/2017:14:42:35 +0800] "GET /post/54079.html HTTP/1.1" "200" 28328 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36" "1.1.1.1" "-" 0.000 28716 412 

其中 183.131.24.75 是 CDN 回源的 IP ,也就是$remote_addr 这个 IP 是无法伪造的,而我们可以看到 1.1.1.1 对应的就是$http_x_forwarded_for 这个 IP 实际是伪造的。

所以,仅仅通过 X-Forwarded-For 来判断真实 IP 是不可靠的。

那么,利用这个漏洞能干嘛?

现在很多网站登录的时候都会针对同一 IP 源进行限制访问次数,或者投票系统,如果以 X-Forwarded-For 作为判断真实 IP 为依据,则很轻易的就会被绕过限制进行暴力破解和刷票。

via.https://awen.me/post/16558.html

最后修改:2018 年 08 月 15 日 05 : 52 AM