教你利用HTTP host头攻击的技术

1、利用HTTP host头攻击的技术2014-04-10我来说两句作者：龙臣收藏，胃.我要投稿from:/2013/05/practical-http-host-header-at tacks.html0 x00背景一般通用web程序是如果想知道网站域名不是一件简单的事情，如果用一个固定的URI来作为域名会有各种麻烦。开发人员一般是依赖HTTP Host header(比如在php里是_SERVERHTTP_HOST)，而这个header很多情况下是靠不住的。而很多应用是直接把这个值不做html编码便输出到了页面中，比如：?1 link href=http:/ SERVERHOST (Jooml

2、a)还有的地方还包含有secret key和token，? (Django, Gallery, others)这样处理问题一般会很容易遭遇到两种常见的攻击：缓存污染和密码重置。缓存污染是指攻击者通过控制一个缓存系统来将一个恶意站点的页面返回给用户。密码重置这种攻击主要是因为发送给用户的内容是可以污染的，也就是说可以间接的 劫持邮件发送内容。0 x01密码重置污染攻击拿Gallery这个站来做例子。当我们进行密码重置的时候，网站会给我们发 送一个随机的key：$user - hash = random:hash();$message - confirm_url =url:abs_site(pas

3、sword/do_reset?key=$user-hash);当用户点击重置密码的链接时，肯定可以说明点的是自己的账户。Password Reset Request dnnineKnii)pIc.coinJsn L2 船to前白Password re-set requestEll。，G=alleiy Administrator.We received a request lo reset your password lar / If /ou made this request, you can confirm it by licking thisli ff you di tint 陷 qu帖！

4、& tmc psis ord res&t. its -ok co ignior Uhis msall.届，C lick h&re to Rgjply o r Fcirw目rdErto.eviLc orn/index,p hp巾 a sswo rd/da_rEset ?lcey= dBSOL6 493 53。9POST /password/resetHTTP/1.1Host: .csrf=1e8d5c9bceb16667b1b330cc5fd48663&name=admin这个漏洞在Django，Piwik和Joomla中都存在，还有一些其他的应用，框架 和类库。当然这种攻击方式一定要能骗取用户

5、点击访问这个受污染的链接，如果用户警 觉了没有点击，那么攻击就会失败。当然你自己也可以配合一些社会工程学的方法 来保证攻击的成功率。还有一些情况，Host可能会被url编码后直接放到email的header里面造成 header注入。通过这个，攻击者可以很容易的就能劫持用户的账户。0 x02缓存污染通过Host header来污染缓存的攻击方法最初是Carlos Beuno在2008年提出 来的。但是在现在的网络架构中，这种攻击还是比较困难的，因为现在的缓存设备都能够识别Host。比如对于下面的这两种情况他们绝对不会弄混淆： GET /index.html HTTP/1.1 GET /inde

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

7、可能受到污染。比如Joomla就将取得的host值不经html 编码便写进任意页面，而它的缓存则对这些没有任何处理。比如可以通过下面的请 求来写入一个存储型的xss：1 curl -H Host: cowonerror=alert(1)rel=stylesheet HYPERLINK , .实际上的请求是这样的： GET / HTTP/1.1 Host: cowonerror=alert(1)rel=stylesheet.响应其实已经受到污染：1 POST /en-US/firefox/user/pwresetHTTP/1.1Host: X-Forwarded-Host: 即使Django给出

8、了补丁，但是依然存在风险。Webserver允许在host header 里面指定端口，但是它并不能通过端口来识别请求是对应的哪个虚拟主机。可以通 过下面的方法来绕过：? POST /en-US/firefox/user/pwreset HTTP/1.1 Host: :这直接会导致生成一个密码重置链接：:/users/pwreset/3f6hp/3ab-9a e3db614fc0d0d036d4当用户点击这个链接的时候就会发现，其实这个key已经被发送到 这个站点了。在我报告了此问题后，Django又推出了一个补丁： HYPERLINK /weblog/2012/oct/17/security

9、/ /weblog/2012/oct/17/security/不幸的是，这个补丁只是简单的通过黑名单方式来简单的过滤掉了和其他一 些字符。而由于密码重置链接是以纯文本而不是html的方式发送的，所以此补丁只 需要添加一个空格就可以绕过： POST /en-US/firefox/users/pwreset HTTP/1.1 Host: : HYPERLINK Django的后续补丁规定了 host header的端口部分只能是含有数字，以规避此 问题。但是在RFC2616文档中规定了，如果请求URI是一个绝对的URI，那么host是Request-URI的一部分。在请求中的任何Host head

10、er值必须被忽略。也就是说，在Apache和Nginx (只要是遵守此文档的webserver)中，可以通 过绝对uri向任意应用发送一个包含有任意host header的请求：? POST HYPERLINK /en-US/firefox/users/pwreset /en-US/firefox/users/pwreset HTTP/1.1 Host: 这个请求在SERVER_NAME里面的值是，而不是host里的 。应用可以通过使用SERVER_NAME而不是host header来规避此风险，但 是如果没有配合特殊配置的webserver，这个风险依然存在。可以在这里 HYPERLINK

11、 /questions/2297403/http-host-vs-server-name/2297 /questions/2297403/http-host-vs-server-name/2297 421#2297421 看看 HTTP_HOST 和 SERVER_NAME 的区别。Django 官方在 2013 年的二 月通过强制使用一个host白名单来修复了此问题。尽管如此，在很多其他的wen 应用上，这种攻击方式依然屡试不爽。0 x04服务器方面需要做的由于http请求的特点，host header的值其实是不可信的。唯一可信的只有SERVER_NAME，这个在Apache和Nginx里可以通过设置一个虚拟机来记录所有的非 法host header。在Nginx里还可以通过指定一个SERVER_NAME名单，Apache也可 以通过指定一个SERVER_NAME名单并开启UseCanonicalName选项。建议两种方法同 时使用。Varnish很快会发布一个补丁。在官方补丁出来前，可以通过在配置文件里加入：?1 import std;2sub vcl_recv (std.collect(req. HYPERLINK http:/http.host http.host);来防护。0 x05应用本身