文/Nick Sullivan翻譯/Tao Wan

防止惡意請(qǐng)求循環(huán)

文/Nick Sullivan1翻譯/Tao Wan2

Web是一個(gè)協(xié)作的生態(tài)系統(tǒng)。 Web標(biāo)準(zhǔn)的存在，保證了網(wǎng)絡(luò)的參與者以可預(yù)見(jiàn)的方式行事。如果網(wǎng)絡(luò)參與者偏離了既定標(biāo)準(zhǔn)，就會(huì)發(fā)生意想不到的結(jié)果，本文描述的就是這樣一個(gè)意想不到的結(jié)果。

最近一組研究人員發(fā)表在NDSS 2016 的一篇論文 “Forwarding Loop Attacks in the Content Delivery Networks“ （針對(duì)內(nèi)容分發(fā)網(wǎng)絡(luò)的轉(zhuǎn)發(fā)環(huán)路攻擊）［1］中，描述了Web服務(wù)如果以不兼容的方式進(jìn)行交互時(shí)會(huì)發(fā)生什么。他們描述的攻擊，惡意用戶可以讓多個(gè)服務(wù)提供商相互發(fā)送其請(qǐng)求，從而導(dǎo)致無(wú)休止的循環(huán)。這樣的請(qǐng)求循環(huán)可以導(dǎo)致服務(wù)供應(yīng)商的資源枯竭和服務(wù)拒絕。該論文還展示了，轉(zhuǎn)發(fā)環(huán)路攻擊對(duì)大批的CDN是可行的。

針對(duì)上述論文提到的攻擊，我們已經(jīng)對(duì)CloudFlare的服務(wù)做了相應(yīng)的修改，使之符合于HTTP代理的相關(guān)標(biāo)準(zhǔn)。然而要徹底避免上述攻擊，所有的代理服務(wù)必須都遵循相關(guān)標(biāo)準(zhǔn)。如果有一個(gè)服務(wù)供應(yīng)商不遵循標(biāo)準(zhǔn)，其他所有遵循標(biāo)準(zhǔn)的服務(wù)商，仍然可以被攻擊。在本文中，我們將介紹這種新型的攻擊，并說(shuō)明一個(gè)供應(yīng)商如何從問(wèn)題的一部分，變成解決方案的一部分。

反向代理

CloudFlare 是使用反向代理來(lái)工作的。當(dāng)HTTP（S）請(qǐng)求進(jìn)入CloudFlare的網(wǎng)絡(luò)，會(huì)發(fā)生下面的兩種情況之一：一是CloudFlare返回緩存的響應(yīng)；二是CloudFlare向原始網(wǎng)站發(fā)出請(qǐng)求，并轉(zhuǎn)發(fā)原始網(wǎng)站返回的相應(yīng)。CloudFlare可以檢查和修改通過(guò)其網(wǎng)絡(luò)的請(qǐng)求，該能力使得許多強(qiáng)大的功能成為可能，如高速緩存、WAF（Web應(yīng)用防火墻）、RocketLoader等。

另外，在一個(gè)網(wǎng)站的前面使用多個(gè)反向代理也并不少見(jiàn)。這種做法稱(chēng)為堆疊代理（Stacking proxies），通常被用來(lái)提供多個(gè)不同的服務(wù)特性。例如，可以使用CloudFlare進(jìn)行緩存，但使用另外一個(gè)服務(wù)商的WAF。雖然我們更希望客戶使用CloudFlare提供的先進(jìn)的WAF，但使用其他的WAF也是合理的，并且很多客戶也是這么做的。多個(gè)代理可以在原始服務(wù)器的前面被堆疊，但是，如果最后一個(gè)代理指向了第一個(gè)代理會(huì)發(fā)生什么？這將得到一個(gè)代理循環(huán)。

兩個(gè)代理形成的循環(huán)很容易理解。配置第一個(gè)反向代理使用第二反向代理作為源網(wǎng)站，同時(shí)配置第二個(gè)反向代理使用第一個(gè)作為它的源網(wǎng)站，如圖1所示。

從理論上說(shuō)，發(fā)給該網(wǎng)站的任何請(qǐng)求最終會(huì)在兩個(gè)代理之間被來(lái)回發(fā)送。每次循環(huán)都將導(dǎo)致一個(gè)請(qǐng)求被發(fā)送，并消耗資源。幸運(yùn)的是，大多數(shù)反向代理都有保護(hù)，可以避免這樣的簡(jiǎn)單攻擊。

防止簡(jiǎn)單的循環(huán)

HTTP 1.1的作者意識(shí)到請(qǐng)求循環(huán)的可能性，并在制定標(biāo)準(zhǔn)時(shí)，定義了相應(yīng)的保護(hù)。這個(gè)環(huán)路保護(hù)是通過(guò) “Via” 報(bào)頭來(lái)實(shí)現(xiàn)的。下面的段落來(lái)自 RFC 7230的5.7.1部分：

“Via”頭字段，表示在用戶代理和服務(wù)器之間（請(qǐng)求方向），或者在原始服務(wù)器和客戶端之間（響應(yīng)方向），存在中間協(xié)議和接收者。這類(lèi)似于電子郵件的“Received”頭字段（RFC5322 的3.6.7）?！癡ia”頭字段可以用來(lái)向前追蹤消息，從而避免請(qǐng)求循環(huán)，并發(fā)現(xiàn)請(qǐng)求/響應(yīng)鏈中發(fā)件者的協(xié)議功能。

一個(gè)“Via”頭字段的多個(gè)域值可以被用來(lái)表示單個(gè)代理或網(wǎng)關(guān)。每一個(gè)中間人都追加自己的信息，來(lái)表述如何接收到該消息，最終結(jié)果是，所有轉(zhuǎn)發(fā)代理形成了一個(gè)排序。一個(gè)代理在轉(zhuǎn)發(fā)每個(gè)消息時(shí)， 必須按照以下要求，添加相應(yīng)的“Via”頭字段。一個(gè)HTTP到HTTP的網(wǎng)關(guān)必須在每個(gè)入站請(qǐng)求消息中添加 “Via”頭字段，可以在轉(zhuǎn)發(fā)的響應(yīng)消息中添加“Via”頭字段。

圖1

例如，一個(gè)請(qǐng)求消息可以從HTTP / 1.0的用戶代理被發(fā)送到一個(gè)叫“fred”的內(nèi)部代理，該內(nèi)部代理使用HTTP / 1.1把請(qǐng)求轉(zhuǎn)發(fā)到一個(gè)公共代理p.example.net，該公開(kāi)代理則將請(qǐng)求轉(zhuǎn)發(fā)到原始服務(wù)器www.example.com， 從而完成了該次請(qǐng)求。www. example.com接收到的請(qǐng)求將有以下的 Via頭字段：

圖2

Via： 1.0 fred， 1.1 p.example.net

一個(gè)發(fā)送者，不應(yīng)該合并“Via” 的多個(gè)條目，除非它們屬于同一個(gè)組織，并且主機(jī)信息已經(jīng)被匿名化了。如果“Via”的多個(gè)條目包含了不同的協(xié)議值，則絕對(duì)不可以被合并。

CloudFlare目前使用了這一機(jī)制，以防止請(qǐng)求循環(huán)。當(dāng)一個(gè)請(qǐng)求通過(guò)CloudFlare的網(wǎng)絡(luò)時(shí)，并且不在緩存中，CloudFlare將創(chuàng)建一個(gè)新的請(qǐng)求，發(fā)給原始網(wǎng)站。CloudFlare發(fā)出請(qǐng)求的“Via”頭字段中， 包含從上一個(gè)節(jié)點(diǎn)收到請(qǐng)求的HTTP 協(xié)議版本，和一個(gè)CloudFlare專(zhuān)用值：

Via：1.1 CloudFlare

如果一個(gè)請(qǐng)求進(jìn)入“CloudFlare”網(wǎng)絡(luò)時(shí)，其Via頭字段里包含了“cloudflare”這個(gè)值，則會(huì)返回錯(cuò)誤。這可以避免在CloudFlare網(wǎng)絡(luò)中形成請(qǐng)求循環(huán)，如圖2所示。

然而，實(shí)施這種保護(hù)手段，就可以保證CloudFlare不會(huì)受到HTTP請(qǐng)求循環(huán)的攻擊嗎？對(duì)此不要過(guò)快下結(jié)論。

壞消息

并不是所有的反向代理服務(wù)都遵循RFC 7230標(biāo)準(zhǔn)。一些代理服務(wù)給客戶提供過(guò)濾或修改HTTP頭的能力，包括“Via”頭。這其實(shí)是RFC不允許的：代理有義務(wù)保留其他代理添加的“Via”頭字段里的標(biāo)簽。代理只允許修改其自身組織添加的頭部分。允許代理修改其他代理添加的“Via”頭字段，會(huì)導(dǎo)致壞事的發(fā)生。

我們用上面的兩個(gè)代理回路的例子來(lái)解釋。假設(shè)兩個(gè)代理服務(wù)器在發(fā)送請(qǐng)求時(shí)，都會(huì)添加自己的的Via頭，并在收到帶有自己“Via”頭的請(qǐng)求時(shí)，返回錯(cuò)誤。假設(shè)第二個(gè)代理會(huì)把接收到的請(qǐng)求里的“Via”頭過(guò)濾掉。當(dāng)請(qǐng)求從第二代理返回時(shí)，第一個(gè)代理已經(jīng)無(wú)法確認(rèn)它已經(jīng)轉(zhuǎn)發(fā)過(guò)該請(qǐng)求。然后，該請(qǐng)求會(huì)被當(dāng)正常請(qǐng)求一樣處理，被發(fā)送給第二個(gè)代理。第二個(gè)代理如果不做回路檢查，則會(huì)繼續(xù)將該請(qǐng)求發(fā)送回給第一個(gè)代理，如此循環(huán)往復(fù)，如圖3所示。

圖3

這種攻擊可以造成很大的傷害，耗盡兩個(gè)服務(wù)提供商的資源。它還可能導(dǎo)致自動(dòng)攻擊防御系統(tǒng)的意外行為，從而進(jìn)一步導(dǎo)致一個(gè)服務(wù)提供商被另外一個(gè)封鎖。

對(duì)于CloudFlare的客戶

有一些Web服務(wù)器，如果收到的請(qǐng)求包含“Via”頭字段，在缺省情況下，不會(huì)壓縮返回的響應(yīng)。這可以導(dǎo)致你的服務(wù)器在給CloudFlare發(fā)送數(shù)據(jù)時(shí)，浪費(fèi)不必要的帶寬。這時(shí)可以咨詢CloudFlare的知識(shí)庫(kù)，來(lái)學(xué)習(xí)如何測(cè)試所在服務(wù)器是否有此行為，以及如何將其禁用。如果不知該如何修改服務(wù)器的配置，可以聯(lián)系CloudFlare的技術(shù)支持。

呼吁采取行動(dòng)

上述NDSS論文的作者們?cè)谡撐陌l(fā)布之前，聯(lián)系了受影響的CDN廠家，但可能不是所有的廠家都已經(jīng)修復(fù)了。如果所在組織向公眾提供反向代理服務(wù)，我們建議實(shí)現(xiàn)以下邏輯：一是在任何情況下，都不要讓客戶刪除或修改到達(dá)他們網(wǎng)站的請(qǐng)求里的“Via”頭字段。二是進(jìn)行代理時(shí)，追加符合RFC 7230標(biāo)準(zhǔn)的“Via”頭字段。三是如果一個(gè)請(qǐng)求包含你自己的“Via”頭字段，請(qǐng)返回相應(yīng)的錯(cuò)誤。

一個(gè)不符合標(biāo)準(zhǔn)的反向代理服務(wù)可能會(huì)給大家導(dǎo)致不良后果，讓我們一起努力，以避免請(qǐng)求循環(huán)。

（作者單位：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是國(guó)際網(wǎng)絡(luò)安全四大會(huì)議之一，本文獲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/