网络是一个协作的生态系统。网络标准的存在是为了确保网络参与者以可预测的方式行事。如果网络参与者偏离了既定的标准，那么可能会产生意想不到的后果。这篇博文是关于这些意想不到的后果之一。一组研究人员最近发表了一篇论文"内容交付网络中的转发循环攻击"，描述了当web服务以不兼容的方式交互时会发生什么。它们描述了一种攻击，恶意用户可以强迫多个服务提供商在一个循环中向彼此发送无休止的请求流。此请求循环可能导致资源耗尽和服务提供商拒绝服务。本文还证明了该攻击是可行的，并且可以使用大量的服务提供商来执行。CloudFlare的服务已修改为符合HTTP代理的标准。但是，修复导致此攻击的漏洞需要所有代理服务符合相同的标准。即使有一个服务提供商是不兼容的，攻击仍然可以针对兼容的服务执行。在这篇文章中，我们将描述攻击并解释代理服务如何从问题的一部分变成解决方案的一部分。反向代理CloudFlare充当反向代理。当HTTP（S）请求进入CloudFlare的网络时，会发生以下两种情况之一：CloudFlare返回请求的缓存响应，或者CloudFlare向网站的源服务器发出请求并返回该响应。CloudFlare可以检查和修改通过其网络的请求，这一事实使得诸如缓存、WAF、RocketLoader等功能强大。在站点前面放置多个反向代理也很常见。这种做法称为堆叠代理，通常用于启用提供不同功能的多个服务提供商。例如，您可以使用另一个WAF服务和CloudFlare进行缓存。尽管我们更希望客户使用CloudFlare最先进的WAF，但这是一种合理的配置，也是一些CloudFlare客户使用的配置。代理可以堆叠在原始服务器前面，但是如果堆栈中的最后一个代理指向第一个代理，会发生什么情况？你得到一个代理循环。两个代理循环很容易想象。配置第一个反向代理服务以使用第二个反向代理服务作为其源服务器，然后配置第二个服务以使用第一个作为其源服务器。理论上，对这个站点的任何请求都将在两个代理之间来回发送。此循环的每次迭代都将导致发送请求并使用资源。幸运的是，大多数反向代理服务都有相应的保护措施来避免类似的基本攻击。防止幼稚循环http1.1的作者意识到了请求循环和内置保护作为标准的一部分的潜力。这种循环预防以"Via"报头的形式出现。摘自[RFC 7230]第5.7.1节(https://tools.ietf.org/html/rfc7230\section-5.7.1](https://tools.ietf.org/html/rfc7230\section-5.7.1）："Via"标题字段表示中间产物的存在用户代理和服务器（上）之间的协议和收件人请求）或在源服务器和客户端之间（响应时），类似于电子邮件中的"Received"标题字段（第3.6.7节）[RFC5322]）。Via可用于跟踪消息转发，避免请求循环，并识别发送方的协议功能沿着请求/响应链。…多个Via字段值表示具有转发了消息。每个中介都会附加自己的信息关于如何接收消息，以便最终结果是根据转发收件人的顺序排序。代理必须发送适当的Via头字段，如前所述下面，在它转发的每个消息中。HTTP到HTTP网关必须在每个入站请求中发送适当的Via头字段消息，并且可以在转发响应中发送Via头字段信息。…例如，可以从HTTP/1.0用户发送请求消息代理到代码为"fred"的内部代理，该代理使用HTTP/1.1将请求转发给p的公共代理。示例.net，哪个通过将请求转发到位于的源服务器来完成请求。收到的请求网站那会怎么样具有以下Via标题字段：通过：1.0弗雷德，1.1便士。示例.net发送者不应该合并多个条目，除非它们都是在同样的组织控制下，东道主已经取而代之的是化名。发送方不能合并具有接收到的协议值不同。CloudFlare目前使用这种机制来防止请求循环。当请求通过不在缓存中的CloudFlare网络发出时，CloudFlare将为源服务器创建一个新请求。传出请求得到一个"Via"头，其中包含传入请求的HTTP协议版本和CloudFlare特定的假名，例如：通过：1.1 cloudflare如果Via头中有"cloudflare"的请求进入网络，则返回一个错误。这会使任何循环通过CloudFlare的请求短路。实施这种保护意味着CloudFlare不会受到HTTP请求循环的影响，对吧？不会那么快。坏消息并非所有反向代理服务都符合rfc7230。有些服务使客户能够剥离或修改报头，包括Via报头。这是RFC明确不允许的：代理必须保留来自其他代理的现有标记，作为传入Via头的一部分。代理只允许修改由其自己的组织创建的标头部分。允许代理更改此标头会导致不好的结果。让我们以上面的双代理循环为例。假设两个代理都配置为在传出请求时将它们的标记添加到Via头，并将包含它们自己的Via标记的请求失败。假设两个代理都设置为从传入请求中删除"Via"头。当请求从第二个代理返回时，第一个代理无法识别它已经代理了该请求。然后将此请求视为常规请求，使第一个代理向第二个代理发出请求，第二个代理将头剥离并发回，依此类推。这种攻击会造成很大的破坏，耗尽两个服务提供商的资源。它还可能导致自动攻击预防系统中的意外行为，导致一个服务提供商被另一个服务提供商阻止。不用说，这并不理想。针对CloudFlare客户默认情况下，如果请求中存在Via头，某些web服务器不会压缩传出响应。这可能会导致源站使用不必要的带宽将数据发送到CloudFlare。请参阅CloudFlare知识库，了解如何测试服务器是否存在此行为以及如何禁用它。如果您无法修改服务器的配置，请与支持人员联系。行动号召论文作者在发表这篇论文之前联系了受影响的各方，但并非所有人都采取了行动。如果您的组织向公众提供反向代理服务，我们建议您实现以下逻辑：在任何情况下，都不允许客户通过标题删除或修改对其站点的请求。当代理流量时，附加一个rfc7230兼容的Via头。如果请求随Via头一起进来，则返回相应的错误。一个不兼容的反向代理服务可能会给每个人带来负面影响，让我们一起努力避免请求循环。我要感谢陶婉、陈建军、江建江、梁金进与我们合作解决问题。我还要特别感谢Pasha Kravtsov帮助调查这一问题，并感谢Rajeev Sharma为我们的Via实施提供帮助。