我们来看看如果指定的是一个无效的host头会发生什么?大多数web服务器被配置为将无法识别的host头传送到列表中的第一台虚拟主机之上。因此,这使得把携带有任意host头的请求发送到第一台虚拟主机上是完全可能的。 另一种传送任意host头的方法是使用X-Forwarded-Host头。在某些配置中,这个头会被主机头的值所重写。因此很可能会产生如下的请求。 GET / HTTP/1.1 Host: www.example.com X-Forwarded-Host: www.attacker.com 许多web应用程序都依赖于HTTP的host头来解读出“他们在何处”。可不幸的是,许多应用程序开发人员没有意识到HTTP的host头是由用户所控制的。正如你可能已经知道的那样,在应用程序的安全理念中,用户的输入应该总是被认为不安全的。因此,在未被正确地得到事先验证之前,请永远不要去信任它们。 虽然在PHP web应用程序中,对于host头的使用是非常普遍的;但是,这实际上并非是PHP web应用程序所独有问题。下面示例中的PHP脚本是一个典型的、危险的host头的用例。 攻击者通过操纵host头,可以操控上面的代码来产生下面这种HTML类型的输出。 - <script src="http://attacker.com/script.js">
一般有两种主要的host头攻击的方法:包括使网页缓存“带毒”,和利用替代渠道来对敏感的操作进行滥用,例如进行密码重置。 网页缓存的中毒 网页缓存的中毒是指攻击者使用该技术来操控网页缓存,并向任何请求页面的人提供带毒的内容。 对于这种情况的发生,攻击者需要使一台缓存代理中毒,而该缓存可以运作在网站本身、或是下游供应商、内容分发网络(CDNs)、连锁合作商或是其他客户机和服务器之间的缓存机制中。该缓存随后将带毒的内容提供给任何请求它的人,而受害者面对这些所提供的恶意内容,无论如何都是没有控制权的。 下面的例子就是攻击者如何通过网页缓存中毒的方式,从而进行host头攻击的。 - $ telnet www.example.com 80
- Trying x.x.x.x...
- Connected to www.example.com.
- Escape character is '^]'.
- GET /index.html HTTP/1.1
- Host: attacker.com
- HTTP/1.1 200 OK
- ...
- <html>
- <head>
- <title>Example</title>
- <script src="http://attacker.com/script.js">
密码重置的中毒 一种普遍的用来实现密码重置功能的方法是:生成一个密钥令牌,并且发送一封包含着该令牌的超级链接的电子邮件。如果一个攻击者请求一个带有attacker-controlled的host头类型的密码重置,会发生什么呢? 如果在生成重置链接时,该web应用程序使用到这个host头的值,攻击者就可以在密码重置链接中“投毒”并发送到受害者那里。而如果受害者点开了邮件中“带毒”的重置链接,那么攻击者将能获得密码重置的令牌,进而可以重置受害者的密码了。 检测密码重置中毒的漏洞 我们将使用一个旧版本的Piwik(一个开源的web分析平台)作为此类漏洞的实例,因为它比较容易受到“带毒”的host头攻击类型的密码重置。 为了检测到密码重置的自动中毒,我们需要依靠一个中介服务,因为对于“带毒”的host头攻击类型的密码重置的检测,需要一个带外的且延时的向量。为了实现此目的,Acunetix(网络漏洞扫描软件)在自动扫描过程中会使用AcuMonitor作为其中介服务。 而在扫描过程中,Acunetix将查找密码重置页面并注入一个自定义的host头,用以指向一个AcuMonitor的域。如果漏洞存在的话,那么有问题的应用程序(如本例中旧版本的Piwik)将使用该值来生成密码重置的链接,并以电子邮件的形式发送给相关的用户。如下所示: 在上面的图片中,请认真查看其重置链接的位置,它指向的是AcuMonitor的域,而不是web应用程序的域。 如果“受害者”(在这个例子中,因为它采取的是自动扫描,受害者很可能是安全团队中的一员,他接收电子邮件后开始进行扫描),点击该链接,AcuMonitor将捕获该请求,并会发回一个通知给Acunetix,指示它应该生成一个“带毒”的host头攻击类型的密码重置的警报。 减缓 减缓和应对host头的攻击,其实非常简单——就是不要信任host头。然而在某些情况下,却是说起来容易做起来难(特别是涉及到遗留下来的旧代码的时候)。如果你必须使用host头作为一种识别web服务器位置的机制的话,我强烈建议你使用包含有各个被允许的主机名的白名单来进行应对。 |