1 http host简单介绍

我们在对系统进行抓包时，通常会发现Http请求header（比如在php里是_SERVER["HTTP_HOST"]）信息里面会带有一个Host字段，首先简单介绍下该host字段是什么。比如一个IP地址可以对应多个域名，比如有这么几个域名www.1.com，www.2.com和www.3.com然后在域名提供商那通过A记录或者CNAME记录的方式最终都和我的虚拟机服务器IP 1.1.1.1.1关联起来，那么我通过任何一个域名去访问最终解析到的都是IP 1.1.1.1。我们甚至可尝试在1.1.1.1上设置更多的网站，让更多的域名解析到一个ip地址上，但是问题来了，应该如何区分不同域名显示的不同内容呢？此时就应该用到host概念了，所有的域名都解析到同一个ip地址，但是每个域名又对应不同的host，通过host可以区分出访问的是服务器上的哪个站点。

2 http host攻击详解

许多web应用程序都依赖于HTTP的host头来解读出“他们在何处”。可不幸的是，许多应用程序开发人员没有意识到HTTP的host头是由用户所控制的。正如你可能已经知道的那样，在应用程序的安全理念中，用户的输入应该总是被认为不安全的。因此，在未被正确地得到事先验证之前，请永远不要去信任它们。

开发人员一般是依赖HTTP Host header（比如在php里是_SERVER[“HTTP_HOST”] ），而这个header很多情况下是靠不住的。而很多应用是直接把这个值不做html编码便输出到了页面中，比如：

还有的地方还包含有token，

这样处理问题一般会很容易遭遇到两种常见的攻击：缓存污染和密码重置。

2.1 缓存污染

网页缓存的中毒是指攻击者使用该技术来操控网页缓存，并向任何请求页面的人提供带毒的内容。

对于这种情况的发生，攻击者需要使一台缓存代理中毒，而该缓存可以运作在网站本身、或是下游供应商、内容分发网络(CDNs)、连锁合作商或是其他客户机和服务器之间的缓存机制中。该缓存随后将带毒的内容提供给任何请求它的人，而受害者面对这些所提供的恶意内容，无论如何都是没有控制权的。

为了能使缓存能将污染后的response返回给用户，我们还必须让缓存服务器看到的host header 和应用看到的host header 不一样。比如说对于Varnish（一个很有名的缓存服务软件），可以使用一个复制的Host header。Varnish是通过最先到达的请求的host header来辨别host的，而Apache则是看所有请求的host，Nginx则只是看最后一个请求的host。这就意味着你可以通过下面这个请求来欺骗Varnish达到污染的目的：

> GET / HTTP/1.1

> Host: example.com

> Host: evil.com

应用本身的缓存也可能受到污染。比如Joomla就将取得的host值不经html编码便写进任意页面，而它的缓存则对这些没有任何处理。比如可以通过

下面的请求来写入一个存储型的xss：

实际上的请求是这样的：

> GET / HTTP/1.1

> Host: cow"onerror='alert(1)'rel='stylesheet'

响应其实已经受到污染：

这时只需要浏览首页看是否有弹窗就知道缓存是否已经被污染了。

2.2 密码重置中毒

一种普遍的用来实现密码重置功能的方法是：生成一个密钥令牌，并且发送一封包含着该令牌的超级链接的电子邮件。如果一个攻击者请求一个带有attacker-controlled的host头类型的密码重置，会发生什么？

如果在生成重置链接时，该web应用程序使用到这个host头的值，攻击者就可以在密码重置链接中“投毒”并发送到受害者那里。而如果受害者点开了邮件中“带毒”的重置链接，那么攻击者将能获得密码重置的令牌，进而可以重置受害者的密码了。

这个地方的漏洞是：url::abs_site 这一部分使用的Hostheader是来自用户重置密码的请求，那么攻击者可以通过一个受他控制的链接来污染密码重置的邮件。

当然这种攻击方式一定要能骗取用户点击访问这个受污染的链接，如果用户警觉了没有点击，那么攻击就会失败。当然你自己也可以配合一些社会工程学的方法来保证攻击的成功率。

3 漏洞验证

通过抓包工具如burpsuite，获取数据包后，如果修改host头仍然能返回正确的数据，则证明该漏洞存在，如果系统返回错误的信息，则证明漏洞不存在

4 安全加固建议

4.1 安全的配置

假设你可以通过任何类型的应用来发起一个http请求，而host header也是可以任意编辑的。虽然在一个http请求里，host header是用来告诉webserver该请求应该转发给哪个站点，但是事实上，这个header的作用或者说风险并不止如此。

比如如果Apache接收到一个带有非法host header的请求，它会将此请求转发给在 httpd.conf 里定义的第一个虚拟主机。因此，Apache很有可能将带有任意host header的请求转发给应用。而Django已经意识到了这个缺陷，所以它建议用户另外建立一个默认的虚拟主机，用来接受这些带有非法host header的请求，以保证Django自己的应用不接受到这些请求。

不过可以通过X-Forwarded-Host 这个header就可以绕过。Django非常清楚缓存污染的风险，并且在2011年的9月份就通过默认禁用X-Forwarded-Host这个header来修复此问题。Mozilla却在addons.mozilla.org站点忽视了此问题，

POST /en-US/firefox/user/pwreset HTTP/1.1

  Host: addons.mozilla.org

  X-Forwarded-Host: evil.com

即使Django给出了补丁，但是依然存在风险。Webserver允许在host header里面指定端口，但是它并不能通过端口来识别请求是对应的哪个虚拟主机。可以通过下面的方法来绕过：

POST/en-US/firefox/user/pwreset HTTP/1.1

Host:addons.mozilla.org:@passwordreset.net

这直接会导致生成一个密码重置链接：
https://addons.mozilla.org:@passwordreset.net/users/pwreset/3f6hp/3ab-9ae3db614fc0d0d036d4

当用户点击这个链接的时候就会发现，其实这个key已经被发送到passwordreset.net这个站点了。在我报告了此问题后，Django又推出了一个补丁：https://www.djangoproject.com/weblog/2012/oct/17/security/

这个补丁只是简单的通过黑名单方式来简单的过滤[email protected]文本而不是html的方式发送的，所以此补丁只需要添加一个空格就可以绕过：

> POST/en-US/firefox/users/pwreset HTTP/1.1

> Host:addons.mozilla.org: www.securepasswordreset.com

4.2 服务器安全配置

由于http请求的特点，host header的值其实是不可信的。唯一可信的只有SERVER_NAME，这个在Apache和Nginx里可以通过设置一个虚拟机来记录所有的非法host header。在Nginx里还可以通过指定一个SERVER_NAME名单，Apache也可以通过指定一个SERVER_NAME名单并开启UseCanonicalName选项。建议两种方法同时使用。