Facebook Notes 中允许用户包含img标签，一旦检测到img标签，Facebook就会用爬虫从外部服务器抓取标签中指定的图片并缓存。正常情况下Facebook对图片只会缓存一次，但利用随机get参数可以绕过这个限制，那么该特性就可以被利用发动一场大流量的HTTP GET洪水攻击。
这个bug的利用步骤已经于2014年3月3号向Facebook Bug奖励计划报告了。
下面为大家解密我是如何做到的：
第一步，创建一组img标签组成的列表，列表中每一项只会被Facebook的爬虫抓取一次。
<img src=http://targetname/file?r=1></img> <img src=http://targetname/file?r=2></img> ... <img src=http://targetname/file?r=1000></img>
第二步，通过m.facebook.com创建notes，其默认会将notes设置为固定长度。
第三步，为同一用户或不同用户创建一些notes，这样每个notes中就包含1000多个http请求。
第四步，同时浏览所有的notes，目标服务器就会受到因大量http get请求而产生的洪水流量攻击了。几秒之内，成千上万的get请求被发往目标服务器。而Facebook的并发服务器总数怎么也得有100+。
Facebook最初不承认这个Bug，因为他们误认为该bug只会导致404请求，不会对网站造成这么大的冲击。
交流过几封电子邮件之后，他们要求我证明该漏洞是否会产生什么大的影响。我将云中的一台虚拟机作为目标，只使用三个笔记本上的浏览器就在2－3个小时内产生了400+Mbps的出站流量。
Facebook服务器数：127
当然，在实战中其造成的冲击应该比400Mbps大得多，因为我只是为了测试，限制了每个浏览器获取图像的数量。我利用该流量图给Facebook写了一个可以产生更大流量的PoC脚本。
4月11日，我收到Facebook的回复说：
感谢你的耐心，很抱歉我的回复有些晚了。我们已经讨论了该问题，与另一个团队也进行了更加深入的讨论。
最后的结论是，在不会明显影响网站整体功能的情况下，我们暂时没有办法真正修复这个问题使其不被用来“攻击”小网站。
遗憾的是，由于所谓的“无法修复”，该bug就不符合bug奖励计划，所以对该问题的报告也就不会有奖励。不过我得承认，你提出攻击思路很有趣，很有创造力，很明显上个月你投入大量精力研究并报告这一问题。我们对此很感激，希望你可以继续向Facebook bug奖励计划提交任何安全问题。
我不知道他们为什么不修复这个问题，在image标签中支持动态链接可能引出其它问题，我不喜欢这种方式。我想，如果用户要在notes中动态生成图片，手动上传可能会更安全一点。
同时我也想到一些因img标签乱用导致的其它问题：
流量放大攻击：如果图片被大尺寸的pdf文件或视频文件代替，Facebook可能会去抓取这些大尺寸文件，但用户获取不到任何东西。
每个Note支持多于1000个连接，每个用户大约能创建100个左右Notes，之后就无法再创建了。而由于创建note时没有验证码，所有这些都可以自动化完成，攻击者可以轻松用多个帐户创建上百个notes，之后一次性同时浏览所有这些notes。
虽然持续400Mbps的流量可能比较危险，但我仍想最后再测试一次，看其是否能对网站造成更大的影响。
这次不再使用浏览器，而是使用PoC脚本，可以达到大约900Mbps的出站流量。
我使用的是一个普通的13M大小的PDF文件，由Facebook去fetch 180000+次，涉及到112台Facebook服务器。
通过流量表可以看到流量几乎维持在895Mbps，可能是因为我使用的这台云虚拟机的能达到的最大流量就是这么多，该虚拟机使用的是一个共享的Gbps以太网口。看起来Facebook服务器根本没有对爬虫做严格的限制，可以想像那些服务器能产生大多的流量。
发现并报告了这一问题之后，我在Google上发现了类似的问题。结合Google与Facebook，我们可以轻松创造Gbps级别的GET洪水流量。
Facebook爬虫将自自己显示为facebookexternalhit。目前看起来现在也没什么其它方法来避免这种麻烦。
[更新]
中提到一种获取属于Facebook爬虫的IP地址的方式：
whois -h whois.radb.net - '-i origin AS32934' | grep ^route
直接阻断IP地址比阻断useragent可能更有效。 |
