緩存投毒漏洞理解

在先知上看到了一篇關于緩存投毒的分享，屬實是小刀拉屁股，開了眼。

但是那篇翻譯的文章屬實還是有點抽象，根據那篇文章，說說我理解的緩存投毒漏洞。

首先利用條件需要目標，存在CDN網絡，或者前置的緩存服務器，可見這也是個富貴病。

1.緩存服務器原理

緩存服務器可以簡單理解為一個map[string]string結構，根據不同key來返回不同的緩存內容。

但是這個key的來源各個cdn或者緩存服務器上就有很大差別，這也就是緩存投毒問題的來源。

以百度的一個靜態資源來看

添加?a以后，緩存時間變了

說明這兩個url對應的是不同的緩存文件，緩存的key可能就是 url的path。

額外請求頭不影響到返回的緩存內容。

2.緩存投毒實例

在Rack 中間件中，會根據用戶傳遞的x-forwarded請求頭，來生成重定向鏈接

x-forwarded-scheme:http
x-forwarded-host:a.com

正常請求時，重定向到內頁

在添加x-forwarded-host請求頭以后，頁面重定向到了我們提供的域名

根據剛才的緩存規則，這個網站如果存在緩存服務器，正常的301頁面會被惡意的301頁面緩存覆蓋，其他普通用戶擊中了我們的緩存就會被重定向到惡意頁面中。

3.前后端服務器差異

除了可控的請求頭外，前后端服務器差異也是緩存投毒的一個重要原因。

根據RFC7230^[1]定義header中\是不合法的，后端服務器應該拒絕請求

但是如果在cdn中未實現此規范，將\轉發到后端服務器，很可能會將400頁面作為url的響應進行緩存，造成正常頁面的DOS。

4.總結

可見緩存投毒產生的原因大部分都是未預期的請求頭，但是大部分所能造成的危害有限。

但是這種攻擊排查起來難度極高，攻擊成本低，可能僅需要一條請求就造成全站DOS。

參考文章

https://xz.aliyun.com/t/10848

References

[1] RFC7230: https://datatracker.ietf.mrg/doc/html/rfc7230