web安全中濫用緩存密鑰規(guī)范化的緩存投毒技術

這篇文章給大家分享的是有關web安全中濫用緩存密鑰規(guī)范化的緩存投毒技術的內容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

10年積累的做網(wǎng)站、成都網(wǎng)站建設經(jīng)驗，可以快速應對客戶對網(wǎng)站的新想法和需求。提供各種問題對應的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡服務。我雖然不認識你，你也不認識我。但先網(wǎng)站設計后付款的網(wǎng)站建設流程，更有夷陵免費網(wǎng)站建設讓你可以放心的選擇與我們合作。

寫在前面的話

眾所周知，如今的網(wǎng)站會包含大量的JavaScript文件/代碼，而這些代碼一般都取自于TypeScript、SCSS和Webpack等復雜的實現(xiàn)棧。為了減少標準網(wǎng)頁的加載時間，開發(fā)人員會利用緩存來減少服務器上的負載并減少用戶的延遲。雖然緩存通常是為了幫助提高服務的可靠性，使其更易于用戶訪問，但一些自定義緩存配置可能會引入拒絕服務漏洞，導致服務易受攻擊。

緩存投毒DoS基礎知識

當攻擊者利用目標設備中的緩存來向每一個請求資源的其他用戶發(fā)送更改響應時，便有可能觸發(fā)緩存投毒漏洞，下面給出的是緩存投毒拒絕服務攻擊的演示樣例：

背景內容

大家可以看到，實現(xiàn)DoS攻擊所需的只是一個未緩存的Header，它將強制源服務器發(fā)送格式錯誤的請求。因此，我決定通過應用以下方法，在一些私人應用程序中尋找潛在的DoS漏洞：

• 通過識別特定的緩存Header（X-Cache和cf-cache-status等）來檢測使用了緩存服務的所有子域名；

• 使用Param Miner來爆破潛在的未緩存的Header；

沒花多少時間，我就在assests.redacted.com中找到了一個緩存投毒DoS漏洞，而這個子域名負責托管其中一個私人應用程序所使用的全部JS和CSS文件。這個漏洞是由Fastify的Accept-Version Header所導致的，它將允許客戶端返回資源的版本描述信息，我可以使用下列方法來利用該功能：

GET /assets/login.js?cb=1                  GET /assets/login.js?cb=1

Host: assets.redacted.com                  Host: assets.redacted.com

Accept-Version: iustin

 

HTTP/1.1 404 Not Found                     HTTP/1.1 404 Not Found

X-Cache: Miss                              X-Cache: Hit

由于緩存密鑰中沒有包含Accept-version Header，因此任意請求JS文件資源的用戶都將收到緩存404響應。令我驚訝的是，這個漏洞竟然讓我拿到了2000美金的漏洞獎勵，因為Fastify并沒有提供金禁用Accept-version Header的選項，該漏洞目前已被標記為了CVE-2020-7764。

然而，在測試了更多的主機之后，越來越明顯的是，我將無法用這種技術找到更多的易受攻擊的目標。因此，我決定對其他可能的緩存投毒DoS小工具做一些額外的研究。

研究過程中，我發(fā)現(xiàn)大多數(shù)技術都討論了非緩存鍵輸入如何導致DoS，但它們忽略了緩存鍵輸入，比如說主機Header或路徑等等。因此，我能夠想出兩個新的攻擊方式，并成功復現(xiàn)一次之前的漏洞。

技術一：主機Header大小寫規(guī)范化

根據(jù)RFC-4343的定義，F(xiàn)QDN（全限定域名）必須是大小寫敏感的，但是在某些情況下，框架并不會嚴格遵循這一點。有趣的是，由于主機值應該不區(qū)分大小寫，一些開發(fā)人員會假設在將主機頭值引入cachekey時寫入小寫字符會是安全的，而不會更改發(fā)送到后端服務器的實際請求。

在將這兩種行為配對時，我能夠使用自定義配置的Varnish作為緩存解決方案在主機上實現(xiàn)以下DoS攻擊：

GET /images/posion.png?cb=1                GET /images/posion.png?cb=1  

Host: cdn.redacted.com                     Host: cdn.redacted.com

 

HTTP/1.1 404 Not Found                     HTTP/1.1 404 Not Found

X-Cache: Miss                              X-Cache: Hit

注意上面大寫的主機Header值，它將導致404錯誤，然后Varnish將使用cache鍵中主機Header的規(guī)范化值來緩存該數(shù)據(jù)。在將該漏洞上報之后，我又拿到了800美金的漏洞獎勵。

分析過程中，我還發(fā)現(xiàn)它的負載均衡器（HAProxy）在接收到了大寫的Header值時，便會響應404錯誤。

除了主機Header之外，參數(shù)和路徑在注入到cachekey之前也可以是小寫的，因此我們應該檢查緩存處理這些數(shù)據(jù)時所采用的機制。

技術二：路徑規(guī)范化

在使用緩存識別子域時，我發(fā)現(xiàn)了一個托管圖像的特定子域。請求一張圖片的請求類似如下：

GET /maps/1.0.5/map/4/151/16.png

Host: maps.redacted.com

跟之前一樣，Param Miner無法找到任何隱藏Header，因此我決定深入分析一下。就我目前所知，路徑中的最后三個數(shù)字是用來告訴服務器應該返回映射的哪一部分范圍。我研究了半天，但啥也沒獲取到。

起初，我認為1.0.5只是一個版本號，所以我沒有太過關注，但令我驚訝的是，當我嘗試1.0.4時，竟然出現(xiàn)了緩存命中的情況。當然，我認為其他一些API可能使用的是舊版本，所以我測試了1.0.0，它也返回了緩存命中的響應。沒過多久我就意識到，無論我用什么替換1.0.5，它都會返回200 OK和一個X-Cache命中響應Header。于是乎，我想出了以下方法：

GET /maps/%2e%2e/map/4/77/16.png          GET /maps/1.0.5/map/4/77/16.png

Host: maps.redacted.com                   Host: maps.redacted.com

 

HTTP/1.1 404 Not Found                    HTTP/1.1 404 Not Found

X-Cache: Miss                             X-Cache: Hit

同樣，在試圖提高緩存命中率時，開發(fā)人員沒有考慮到潛在的DoS攻擊，這使得我可以注入%2e%2e（URL編碼..），并將請求重定向到服務器上不存在的/map/4/77/16.png，從而導致404錯誤。

感謝各位的閱讀！關于“web安全中濫用緩存密鑰規(guī)范化的緩存投毒技術”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！

網(wǎng)頁名稱：web安全中濫用緩存密鑰規(guī)范化的緩存投毒技術
本文地址：http://muchs.cn/article26/gphocg.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供小程序開發(fā)、搜索引擎優(yōu)化、網(wǎng)站導航、靜態(tài)網(wǎng)站、商城網(wǎng)站、網(wǎng)站維護

廣告

聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)