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

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

寫在前面的話

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

緩存投毒DoS基礎(chǔ)知識(shí)

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

背景內(nèi)容

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

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

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

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

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響應(yīng)。令我驚訝的是，這個(gè)漏洞竟然讓我拿到了2000美金的漏洞獎(jiǎng)勵(lì)，因?yàn)镕astify并沒有提供金禁用Accept-version Header的選項(xiàng)，該漏洞目前已被標(biāo)記為了CVE-2020-7764。

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

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

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

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

在將這兩種行為配對時(shí)，我能夠使用自定義配置的Varnish作為緩存解決方案在主機(jī)上實(shí)現(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

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

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

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

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

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

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

Host: maps.redacted.com

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

起初，我認(rèn)為1.0.5只是一個(gè)版本號(hào)，所以我沒有太過關(guān)注，但令我驚訝的是，當(dāng)我嘗試1.0.4時(shí)，竟然出現(xiàn)了緩存命中的情況。當(dāng)然，我認(rèn)為其他一些API可能使用的是舊版本，所以我測試了1.0.0，它也返回了緩存命中的響應(yīng)。沒過多久我就意識(shí)到，無論我用什么替換1.0.5，它都會(huì)返回200 OK和一個(gè)X-Cache命中響應(yīng)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

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

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

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

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

廣告

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