什麼是Web Cache?3分鐘快速帶你瞭解Web Cache的功能及使用方式!

2021/07/13

Web Cache簡介:
Web Cache是一種用來減少網頁伺服器負荷的一種快取技術,藉由判斷請求的資源使否有留存的Cache可以減少後端伺服器進行的運算,Cache可能會存在不同的地方,像是Cache Server、CDN、Reverse Proxy、瀏覽器等等,其中瀏覽器的Cache只會影響單個使用者,而其它類型則會影響複數的使用者。
Web Cache運作方式:
Web Cache的運作方式就是在使用者發出頁面請求時,判斷此請求是否有現有的Cache可以使用,如果沒有才會由Web Server進行運算處理。


Web cache 示意圖


上圖為示意圖

常見的快取控制Header為Cache-Control,內容包含四種不同的狀態和過期時間等等相關資訊,四種狀態如下:
快取控制狀態

實作Web Cache機制時有一個關鍵的地方為如何判斷請求的資源是否相同,而判斷的方法是透過Cache Key,舉個例子:

Cache Key 範例


在上面的請求當中可能透過主要可以判斷資源的一些資訊組成類似”https|GET|test.com|/index.php?arg=1”這樣的Cache Key,具體的內容可能會根據使用的軟體與設定而有不同,其中的請求目標與Host標頭在大多數的Web Cache中都會使用到。

Web Cache Poisoning
介紹
Web Cache Poisoning是一種攻擊者利用快取機制的技術,攻擊者透過製造有害的頁面並使之被快取起來可以攻擊大量的使用者,可透過在Cache過期時再次發送惡意請求來持續的攻擊使用者。

攻擊示意圖


上圖為示意圖

其中的關鍵也就是前面提到的判斷請求資源是否相同的方法,例如沒有放入Cache Key的header不會影響請求的資源,但若是這些header會影響伺服器行為則有機會作為攻擊的輸入點。由於現代的網頁開發會使用到各種框架或CMS,因此有些底層的行為可能是開發者不會注意到的。

常見攻擊流程:
1.尋找可以改變頁面行為但未被放入Cache Key的輸入點 (因為放入Cache Key的話此攻擊請求在資源判斷時會與一般使用者的請求不相符,少部分攻擊是利用Cache Key的機制缺陷)
2.嘗試透過此輸入點製造出惡意行為 (如XSS、redirect等等)
3.使含有惡意行為的頁面被快取起來


常見攻擊的特色為:
• 增加一些攻擊的嚴重性,如反射型XSS可以被儲存起來
• 可以利用一些動態資源,如動態的js和css
• 可以使用一些畸形的請求,只要這些內容不會影響Cache Key,可能使一些self XSS可利用
建議測試時可以用類似加入額外參數或路徑的方式改變Cache Key,避免一般使用者受影響,不過如果遇到下文提到的Internal Cache Poisoning可能無法以安全不影響使用者的方式測試。
10個實際案例,介紹不同的使用情境!


DOM Poisoning or XSS
有些網站使用X-Forwarded-Host作為一些資源的host(如js、png等等),因此會把此header放入頁面中,攻擊者可以因此控制資源來源,或在沒有編碼的情況下直接在頁面產生XSS。


XSS 攻擊


Redirect
有些網站透過X-Forwarded-Host和X-Forwarded-Scheme來重導至資源所在的host,攻擊者除了單純控制導向還可以控制會被Cache的資源(如js)。

控制導向範例


Local Route Poisoning
有些網站透過X-Original-URL來決定實際訪問的頁面,攻擊者可以藉此來做到頁面置換,或者有可能可以繞過一些WAF和安全規則,若是搭配open redirect則有可能可以做到與redirect類似的攻擊。

Local Route Poisoning


Unkeyed Port
有些Cache軟體不會把Host中的port放入Cache Key中,因此攻擊這透過改變port可以造成阻斷服務。

Unkeyed Port


Unkeyed Query String
有些Cache軟體不會把請求目標中的Query String放入Cache Key,因此改變Query String可能也會獲取到Cache起來的頁面,有些透過Query String的XSS可能會因次被忽略。

Unkeyed Query String


如果此頁面會帶著Query String進行跳轉的話則可以透過很長的Query String做到阻斷服務(414 Request-URI Too Large),之所以要透過跳轉是因為有些Cache軟體拒絕Cache像是414這樣的錯誤狀態。

414 Request-URI Too Large


Cache Parameter Cloaking
有些Cache軟體提供一些排除特定query參數的功能,理論上這些特定參數未被反射到頁面上時無法利用,但可能可以透過一些解析url的規則去汙染其它參數。
Cache Parameter Cloaking


Unkeyed Body
Unkeyed Method: 有些Cache軟體不會在Cache Key中放入HTTP Method和body,因此若是POST參數可以製作出惡意頁面的話,一般使用GET請求的使用者也會受影響。


Unkeyed Body


Fat Get: 與上面一樣是利用body,不過是用GET請求傳送,有些網站就算是GET也會使用body作為參數來源,並且也沒有放入Cache Key中。


Cache Key Normalization
大部分Cache軟體會對請求內容做url decode,不過有的時候後端的Web伺服器沒對url做decode就會導致理解差異,可能造成DoS或一些其它影響。
Cache Key Normalization


Cache Key Injection
如果攻擊者可以掌握Cache Key的格式,且Cache Key沒有對使用的特殊字元進行編碼的話可能造成攻擊者可以操縱Cache Key,使一些被放入Cache Key而無法利用的內容有機會被偽造,如底下由PortSwigger團隊研究成員回報的Akamai Cache Key injection。
Cache Key Injection


Internal Cache Poisoning
應用層的Cache軟體可能不會採用Cache Key的機制,而是將回應的部分片段獨立的Cache起來,這會使測試者無法透過Cache Key去避免影響一般使用者,且影響的頁面可能不單只有請求的頁面。
防禦
• 非需要的情況下停用Cache
• 限制Cache的內容為靜態的
• 避免使用未被放入Cache Key的資料產生動態頁面 (有可能是框架中使用到而被忽略)
• 可以嘗試用Vary這個header把會影響頁面的header放入Cache Key (但在引用的Practical Web Cache Poisoning這篇2018年的文章中作者表示有些Cache軟體會忽略這個header)
• 不要忽視任何輸入造成的漏洞,如header造成的XSS
• 確保不要使用GET請求中的body


Reference:
Practical Web Cache Poisoning
Web Cache Entanglement: Novel Pathways to Poisoning

延伸閱讀:
注意!行動裝置App資安檢測最需要注意「防記憶體偵測」技術!
網路詐騙手法!釣魚信件、釣魚網站的社交工程駭客常見3手法!
駭客工具的泛濫VS企業面對的資安威脅



其他訊息