Facebook Notes 允许用户使用<img>标签。每当使用<img>标签时，Facebook会从外部服务器抓取图像，并将其缓存起来。然而Facebook利用随机GET参数只缓存图像一次，该缓存可以被绕过，滥用这个属性会造成巨大的HTTP GET泛洪。

下面是我在2014年3月3日报告给Facebook漏洞奖赏计划的过程。

步骤 1.创建一系列img标签，这些标签只被抓取了一次。

步骤 2. 使用m.facebook.com创建 notes。它默认整理为固定长度。

步骤 3. 相同用户或者不同用户创建多个notes。每一个都会相应1000 多个的http请求。

步骤 4. 同一时间查看所有的notes，目标服务器会观察到有大量的HTTP GET泛洪。成千上万的GET请求在几秒钟发送到一台服务器。并行访问Facebook的服务器的总数是100多。

初始回应：问题被拒绝，因为他们误解了这个bug只会导致一个404的要求，不能够造成高危害。

通过几封邮件后，我被要求举证说明影响。我启动了一个云端上的目标虚拟机，在三台笔记本电脑上只使用浏览器，2-3小时内我实现了400 Mbps的出站流量。

Facebook的服务器数量：127

当然，影响可能会超过400 Mbps的，因为我只使用了浏览器为这个测试，并且我也受由每个获取的图像的域的浏览器线程数量限制。我创建概念验证的脚本，它可能会导致更大的影响和利用图像向Facebook发送脚本。

4月11日，我得到答复：

“感谢您的耐心和我这里的长时间拖延表示歉意。我们对这一问题进行了讨论，并跟另一个团队进行了深入探讨。

最后，得出的结论是，没有好的方式来解决这个问题，不可能不显著降低整体功能而阻止对小型消费级网站的“攻击”。

不幸的是，所谓的“解决不了”的项目就不在奖赏漏洞的计划内，所以不会有奖励这个问题。但我想表示感谢，而且我觉得c提出的攻击是有趣的，你显然做了很多工作。我们也希望您继续提交您找到Facebook的漏洞。”

我不知道为什么他们不能解决。在图像标签支持动态链接可能是一个问题，我不是它的忠实粉丝。如果他们想有动态生成的图像，我觉得手动上传就能满足用户的需要。

我也看到了这种类型滥用的一些其他问题：

• 流量放大的情况下：当图像被替换为较大尺寸的PDF或视频时， Facebook会捕获到一个巨大的文件，但用户什么也得不到。

每个notes支持1000多条链接，和Facebook会锁定用户在产生100个信息后。由于没有验证码的注释产生，所有这一切都可以实现自动化，攻击者可以使用多个用户轻松准备数百个说明虽然持续400 Mbps可能是危险的，但我这测试是最后一次，看它是否确实能有较大的影响。不使用浏览器，而使用POC脚本我能搞定 900 Mbps的出站流量。

我使用了一个普通的13 MB的PDF文件，被Facebook的处理了180,000多次，涉及Facebook的服务器数量是112。

我们可以看到流量图是在895 Mbps上下浮动的。这可能是因为施加于我的虚拟机在其上使用共享Gbps的以太网端口云计算的最大流量的限制。但这似乎没有限制在Facebook的服务器上，所以我们可以想象到底能获取多少流量。

发现并报告此问题后，我发现谷歌上的类似的问题。结合谷歌和Facebook ，似乎我们可以很容易得到Gbps的流量。
Facebook的处理功能显示自己可以作为facebook的扩展工具。现在它似乎没有其他的选择，而必须阻止它，以避免这种滋扰。

[更新1]
https://developers.facebook.com/docs/ApplicationSecurity/提到提到一种方式来获得Facebook获取的IP地址。

阻塞IP地址可能会比阻止用户代理更有效。我在博客上已经得到了很多的回应，并想感谢DOSarrest团队承认这个发现。

[更新 2]

POC脚本和访问日志现在可以从Github上访问。这个脚本非常简单，仅仅是一个粗略的草稿。请使用它们仅用于研究和分析。

访问日志是我用于900 Mbps的测试的确切的日志。在访问日志，你会发现来自Facebook 300,000 多的请求。以前，我只计算了facebookexternalhit/1.1 ，似乎每个IMG标签，有两个攻击，即一个来自1.0版本。另一个则是1.1的。我也尝试了谷歌，你也会发现来自谷歌的700多条数据。