构造HTTP请求Header实现"伪造来源IP"

谁践踏了优雅 2022-06-11 08:55 221阅读 0赞

构造 HTTP请求 Header 实现“伪造来源 IP ”

在阅读本文前，大家要有一个概念，在实现正常的TCP/IP 双方通信情况下，是无法伪造来源 IP 的，也就是说，在 TCP/IP 协议中，可以伪造数据包来源 IP ，但这会让发送出去的数据包有去无回，无法实现正常的通信。这就像我们给对方写信时，如果写出错误的发信人地址，而收信人按信封上的发信人地址回信时，原发信人是无法收到回信的。

一些DDoS 攻击，如 SYN flood,  就是利用了 TCP/ip 的此缺陷而实现攻击的。《[计算机网络][Link 1]》教材一书上，对这种行为定义为“发射出去就不管”。

因此，本文标题中的伪造来源IP 是带引号的。并非是所有 HTTP 应用程序中存在此漏洞。

那么在HTTP 中， " 伪造来源 IP",  又是如何造成的？如何防御之？

在理解这个原理之前，读者有必要对HTTP 协议有所了解。 HTTP 是一个应用层协议，基于请求 / 响应模型。客户端（往往是浏览器）请求与服务器端响应一一对应。

请求信息由请求头和请求正文构成（在GET 请求时，可视请求正文为空）。请求头类似我们写信时信封上的基本信息，对于描述本次请求的一些双方约定。而请求正文就类似于信件的正文。服务器的响应格式，也是类似的，由响应头信息和响应正文构成。

为了解这个原理，可使用Firefox Firebug,  或 IE 浏览器插件 HTTPwatch 来跟踪 HTTP 请求 / 响应数据。

本文中，以HTTPwatch 为例说明之。安装 httpwatch 并重启 IE 浏览器后， IE 的工具栏上出现其图标，点击并运行 Httpwatch,  就会在浏览器下方显示出 HTTPWatch 的主界面。

![SouthEast][]

点击左下角红色的“Record ”按钮，并在地址栏输入 www.baidu.com,  等页面打开后，选中一个请求，并在下方的 tab 按钮中选择“ Stream ”，如图：

![SouthEast 1][]

左边即是请求数据，右边即是服务器响应数据。左边的请求头均以回车换行结束，即“\\r\\n ” ,  最后是一个空行（内容为 \\r\\n ） , 表示请求 header 结束。而请求 header 中除第一行外，其它行均由 header 名称， header 值组成，如  Accept-Encoding: gzip, deflate ， header 名称与值之间有冒号相隔，之间的空格是可有可无的。

那么，在HTTP 应用程序中，如何取得指定的请求 header 信息呢？这里使用 [PHP][] 语言为例说明。对所有客户端请求 header, [php][PHP] 程序中取得其值的方式如下：   
$\_SERVER\['HTTP\_ ***HEADER\_NAME*** '\]

HEADER\_NAME应该以换成对应的 header 名称，此项的规律是：全大写，连接线变成下划线。比如要取得客户端的User-Agent 请求头，则使用 $\_SERVER\['HTTP\_USER\_AGENT'\],  掌握这个规律，即可达到举一反三的效果。如要取得 COOKIE 信息，则使用 $\_SERVER\['HTTP\_COOKIE'\] 即可。也就是说， $\_SERVER 数组中，以 HTTP 开头的项均属于客户端发出的信息。

回归到HTTP 应用程序层，来源 IP 的重要性不言而语，例如表单提交限制，频率等等均需要客户端 IP 信息。使用流行的 Discuz X2.5  的文件 source/class/discuz/discuz\_application.php 中的代码片断：

private function \_get\_client\_ip() \{

$ip = $\_SERVER\['REMOTE\_ADDR'\];

if (isset($\_SERVER\['HTTP\_CLIENT\_IP'\]) && preg\_match('/^(\[0-9\]\{1,3\}\\.)\{3\}\[0-9\]\{1,3\}$/', $\_SERVER\['HTTP\_CLIENT\_IP'\])) \{

$ip = $\_SERVER\['HTTP\_CLIENT\_IP'\];

如以下的JSP代码片段：  
public String getIpAddr(HttpServletRequest request) \{  
       String ip = request.getHeader("x-forwarded-for");  
       if(ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) \{  
          ip = request.getHeader("Proxy-Client-IP");  
       \}  
       if(ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) \{  
          ip = request.getHeader("WL-Proxy-Client-IP");  
       \}  
       if(ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) \{  
          ip = request.getRemoteAddr();  
       \}  
       return ip;  
\}

以上代码片段即是获取客户端IP ，这段程序会尝试检查 HTTP\_CLIENT\_IP, HTTP\_X\_FORWARDED\_FOR,  根据之前的原理说明，以 HTTP\_ 开头的 header,  均属于客户端发送的内容。那么，如果客户端伪造 Client-Ip, X-Forward-For ，不就可以欺骗此程序，达到“伪造 IP ”之目的？

那么如何伪造这项值？如果你会写程序，并了解HTTP 协议，直接伪造请求 header 即可。或者使用 Firefox 的Moify Headers 插件即可。

![SouthEast 2][]

![SouthEast 3][]

按图示顺序号输入或点击相应按钮。Start 按钮这里变为红色 Stop ，说明设置成功。

这时，如果我们使用Firefox 访问其它网站，网站服务器就针接收到我们伪造的 X-Forward-For,  值为 1.1.1.1 。

严格意义上讲，这并不是程序中的漏洞。Discuz 为了保持较好的环境兼容性 ( 包含有反向代理的 web 服务器环境，如 nginx 作为 php fastcgi 的前端代理 ) ，如此处理是可以理解的。那么如何处理，才能杜绝这个问题呢？

**服务器重新配置X-Forward-For 为正确的值。**

如对典型的nginx + php fastcgi 环境（ nginx 与 php fastcgi 是否位于同一机器，并不妨碍此问题的产生） , nginx和 php fastcig 进程直接通信：

切记，$\_SERVER\['REMOTE\_ADDR'\]  是由 nginx 传递给 php 的参数，就代表了与当前 nginx 直接通信的客户端的 IP （是不能伪造的）。

再比如，存在中间层代理服务器的环境：

![SouthEast 4][]

这种情况下，后端的HTTP 文件服务器上获取取的 REMOTE\_ADDR 永远是前端的 squid/varnish cache 服务器的通信 IP 。

服务器集群之间的通信，是可以信任的。我们要做的就是在离用户最近的前端代理上，强制设定X-Forward-For 的值，后端所有机器不作任何设置，直接信任并使用前端机器传递过来的 X-Forward-For 值即可。

即在最前端的Nginx 上设置：

location  ~  ^/static \{

proxy\_pass  ....;

**proxy\_set\_header X-Forward-For $remote\_addr ;**

如果最前端（与用户直接通信）代理服务器是与php fastcgi 直接通信，则需要在其上设定：

location ~ "\\.+\\.php$" \{

fastcgi\_pass localhost:9000;

**fastcgi\_param  HTTP\_X\_FORWARD\_FOR  $remote\_addr;**

记住，$remote\_addr 是 nginx 的内置变量，代表了客户端真实（网络传输层） IP 。通过此项措施，强行将 X-Forward-For 设置为客户端 ip,  使客户端无法通过本文所述方式“伪造 IP ”。

LVS转发环境下，是否存在此问题？

LVS工作在网络层，不改变来源及目标 IP ，更不可能更改应用层信息，故不存在此问题。如果有任何疑惑或需要帮助，请联系笔者信箱 zhangxugg@163.com。

存在此问题的程序:

所有版本的discuz, phpcms, phpwind, dedeCMS 。以及其它可能未知的程序。

例如使用Modify Headers 进行 IP 伪装之后再登录 bbs.phpchina.com ，我们查看自己的个人资料中的“上次访问IP ”就发现就是我们伪装的数据。

可以说，互联网上存在此漏洞的网站实在是太多了。试试便知。那么对于存在此漏洞，并且使用IP 作限制的网站，一定要小心。

转载自：http://blog.csdn.net/shimiso/article/details/17913331

[Link 1]: http://lib.csdn.net/base/computernetworks
[SouthEast]: /images/20220611/584773c7457b45e1ae619813a1e821b4.png
[SouthEast 1]: /images/20220611/a56af9fe3013478f87fa5f8888fa0dd8.png
[PHP]: http://lib.csdn.net/base/php
[SouthEast 2]: /images/20220611/ce3f362af67d456ca202b81ec325da48.png
[SouthEast 3]: /images/20220611/a82e3640a82d46b4aad1e5b471032015.png
[SouthEast 4]: /images/20220611/3c5cc746fb4540b58719896e9a2776ef.png