防止恶意请求循环

2016-09-14 05:55NickSullivan翻译TaoWan
中国教育网络 2016年7期
关键词:代理服务服务提供商代理

文/Nick Sullivan翻译/Tao Wan

防止恶意请求循环

文/Nick Sullivan1翻译/Tao Wan2

Web是一个协作的生态系统。 Web标准的存在,保证了网络的参与者以可预见的方式行事。如果网络参与者偏离了既定标准,就会发生意想不到的结果,本文描述的就是这样一个意想不到的结果。

最近一组研究人员发表在NDSS 2016 的一篇论文 “Forwarding Loop Attacks in the Content Delivery Networks“ (针对内容分发网络的转发环路攻击)[1]中,描述了Web服务如果以不兼容的方式进行交互时会发生什么。他们描述的攻击,恶意用户可以让多个服务提供商相互发送其请求,从而导致无休止的循环。这样的请求循环可以导致服务供应商的资源枯竭和服务拒绝。该论文还展示了,转发环路攻击对大批的CDN是可行的。

针对上述论文提到的攻击,我们已经对CloudFlare的服务做了相应的修改,使之符合于HTTP代理的相关标准。然而要彻底避免上述攻击,所有的代理服务必须都遵循相关标准。如果有一个服务供应商不遵循标准,其他所有遵循标准的服务商,仍然可以被攻击。在本文中,我们将介绍这种新型的攻击,并说明一个供应商如何从问题的一部分,变成解决方案的一部分。

反向代理

CloudFlare 是使用反向代理来工作的。当HTTP(S)请求进入CloudFlare的网络,会发生下面的两种情况之一:一是CloudFlare返回缓存的响应;二是CloudFlare向原始网站发出请求,并转发原始网站返回的相应。CloudFlare可以检查和修改通过其网络的请求,该能力使得许多强大的功能成为可能,如高速缓存、WAF(Web应用防火墙)、RocketLoader等。

另外,在一个网站的前面使用多个反向代理也并不少见。这种做法称为堆叠代理(Stacking proxies),通常被用来提供多个不同的服务特性。例如,可以使用CloudFlare进行缓存,但使用另外一个服务商的WAF。虽然我们更希望客户使用CloudFlare提供的先进的WAF,但使用其他的WAF也是合理的,并且很多客户也是这么做的。多个代理可以在原始服务器的前面被堆叠,但是,如果最后一个代理指向了第一个代理会发生什么?这将得到一个代理循环。

两个代理形成的循环很容易理解。配置第一个反向代理使用第二反向代理作为源网站,同时配置第二个反向代理使用第一个作为它的源网站,如图1所示。

从理论上说,发给该网站的任何请求最终会在两个代理之间被来回发送。每次循环都将导致一个请求被发送,并消耗资源。幸运的是,大多数反向代理都有保护,可以避免这样的简单攻击。

防止简单的循环

HTTP 1.1的作者意识到请求循环的可能性,并在制定标准时,定义了相应的保护。这个环路保护是通过 “Via” 报头来实现的。下面的段落来自 RFC 7230的5.7.1部分:

“Via”头字段,表示在用户代理和服务器之间(请求方向),或者在原始服务器和客户端之间(响应方向),存在中间协议和接收者。这类似于电子邮件的“Received”头字段(RFC5322 的3.6.7)。“Via”头字段可以用来向前追踪消息,从而避免请求循环,并发现请求/响应链中发件者的协议功能。

一个“Via”头字段的多个域值可以被用来表示单个代理或网关。每一个中间人都追加自己的信息,来表述如何接收到该消息,最终结果是,所有转发代理形成了一个排序。一个代理在转发每个消息时, 必须按照以下要求,添加相应的“Via”头字段。一个HTTP到HTTP的网关必须在每个入站请求消息中添加 “Via”头字段,可以在转发的响应消息中添加“Via”头字段。

图1

例如,一个请求消息可以从HTTP / 1.0的用户代理被发送到一个叫“fred”的内部代理,该内部代理使用HTTP / 1.1把请求转发到一个公共代理p.example.net,该公开代理则将请求转发到原始服务器www.example.com, 从而完成了该次请求。www. example.com接收到的请求将有以下的 Via头字段:

图2

Via: 1.0 fred, 1.1 p.example.net

一个发送者,不应该合并“Via” 的多个条目,除非它们属于同一个组织,并且主机信息已经被匿名化了。如果“Via”的多个条目包含了不同的协议值,则绝对不可以被合并。

CloudFlare目前使用了这一机制,以防止请求循环。当一个请求通过CloudFlare的网络时,并且不在缓存中,CloudFlare将创建一个新的请求,发给原始网站。CloudFlare发出请求的“Via”头字段中, 包含从上一个节点收到请求的HTTP 协议版本,和一个CloudFlare专用值:

Via:1.1 CloudFlare

如果一个请求进入“CloudFlare”网络时,其Via头字段里包含了“cloudflare”这个值,则会返回错误。这可以避免在CloudFlare网络中形成请求循环,如图2所示。

然而,实施这种保护手段,就可以保证CloudFlare不会受到HTTP请求循环的攻击吗?对此不要过快下结论。

坏消息

并不是所有的反向代理服务都遵循RFC 7230标准。一些代理服务给客户提供过滤或修改HTTP头的能力,包括“Via”头。这其实是RFC不允许的:代理有义务保留其他代理添加的“Via”头字段里的标签。代理只允许修改其自身组织添加的头部分。允许代理修改其他代理添加的“Via”头字段,会导致坏事的发生。

我们用上面的两个代理回路的例子来解释。假设两个代理服务器在发送请求时,都会添加自己的的Via头,并在收到带有自己“Via”头的请求时,返回错误。假设第二个代理会把接收到的请求里的“Via”头过滤掉。当请求从第二代理返回时,第一个代理已经无法确认它已经转发过该请求。然后,该请求会被当正常请求一样处理,被发送给第二个代理。第二个代理如果不做回路检查,则会继续将该请求发送回给第一个代理,如此循环往复,如图3所示。

图3

这种攻击可以造成很大的伤害,耗尽两个服务提供商的资源。它还可能导致自动攻击防御系统的意外行为,从而进一步导致一个服务提供商被另外一个封锁。

对于CloudFlare的客户

有一些Web服务器,如果收到的请求包含“Via”头字段,在缺省情况下,不会压缩返回的响应。这可以导致你的服务器在给CloudFlare发送数据时,浪费不必要的带宽。这时可以咨询CloudFlare的知识库,来学习如何测试所在服务器是否有此行为,以及如何将其禁用。如果不知该如何修改服务器的配置,可以联系CloudFlare的技术支持。

呼吁采取行动

上述NDSS论文的作者们在论文发布之前,联系了受影响的CDN厂家,但可能不是所有的厂家都已经修复了。如果所在组织向公众提供反向代理服务,我们建议实现以下逻辑:一是在任何情况下,都不要让客户删除或修改到达他们网站的请求里的“Via”头字段。二是进行代理时,追加符合RFC 7230标准的“Via”头字段。三是如果一个请求包含你自己的“Via”头字段,请返回相应的错误。

一个不符合标准的反向代理服务可能会给大家导致不良后果,让我们一起努力,以避免请求循环。

(作者单位:1为CloudFlare;2为Huawei Canada)

[1] Jianjun Chen, Jian Jiang, Xiaofeng Zheng, Haixin Duan, Jinjin Liang, Tao Wan, Kang Li, Vern Paxson, Forwarding-Loop Attacks in Content Delivery Networks, accepted by NDSS 2016 。NDSS是国际网络安全四大会议之一,本文获NDSS 2016年杰出论文(Distinguished Paper)。

[2]论文下载:http://netsec.ccert.edu.cn/duanhx/files/2010/12/cdn_loop-final-cameraready.pdf

[3]原文地址: https://blog.cloudflare.com/preventing-malicious-request-loops/

猜你喜欢
代理服务服务提供商代理
论品牌出海服务型跨境电商运营模式
代理圣诞老人
最新调查:约三成云服务提供商正迅速改变其业务模式
农村“三资”代理服务浅析
网络非中立下内容提供商与服务提供商合作策略研究
网络安全与防火墙技术
108名特困生有了“代理妈妈”
胜似妈妈的代理家长
一个村有二十六位代理家长
电信增值信息服务若干问题研究