【技術分享】梨子帶你刷burpsuite靶場系列之高級漏洞篇 - Web緩存投毒專題
高級漏洞篇介紹
相對于服務器端漏洞篇和客戶端漏洞篇，高級漏洞篇需要更深入的知識以及更復雜的利用手段，該篇也是梨子的全程學習記錄，力求把漏洞原理及利用等講的通俗易懂。
Web緩存投毒專題
什么是Web緩存投毒？
首先了解一下什么是Web緩存，Web緩存就是服務器會先將之前沒見過的請求對應的響應緩存下來，然后當有認為是相同請求的時候直接將緩存發給用戶，這樣可以減輕服務器的負荷。但是服務器端在識別的時候是根據特征來的，如果兩個請求的特征相同即會認為是相同的請求，此時如果攻擊者首先觸發服務器緩存附有惡意payload的響應，當其他用戶發送相同請求時即會接收到這個惡意的響應。從影響范圍來看，一旦成功緩存被投毒的響應，會影響到大量的用戶，比起以往某些只能針對某個用戶發起的攻擊，危害大很多很多。
Web緩存的流程是什么樣的？
其實前面梨子已經講了差不多了，這一小節主要是補充講解。其實這個Web緩存不是永久的，它只保存固定的一段時間，過了這個時間以后就會重新生成緩存，所以這類攻擊還是有一定難度的。那么服務器端怎么識別等效的請求呢，我們接下來介紹一下緩存鍵的概念。
緩存鍵
緩存鍵就是服務器端用來識別等效請求的一系列特征的統稱。一般緩存鍵包括請求行和Host頭。服務器端只識別設置為緩存鍵的特征是否相同，這也就導致了Web緩存投毒漏洞的產生。
如何構造Web緩存投毒攻擊？
一般構造Web緩存投毒攻擊需要以下幾個步驟
- 識別并確認不會被緩存的輸入
- 從服務器誘發被投毒的響應
- 得到被緩存的響應
識別并確認不會被緩存的輸入
我們想要構造Web緩存投毒就需要我們的輸入能夠反饋在響應中，但是如果我們的輸入被設置為緩存鍵，那就不可能有用戶發出等效請求，所以我們需要不斷調試直到找到我們的輸入既不會是緩存鍵又可以被反饋在被緩存的響應中。這樣才能保證被投毒的響應緩存被投放到受害者那里，burp推薦了一款插件Param Miner來輔助我們尋找這樣的不會被緩存的字段。
Param Miner
這款插件會自動去檢測不會被緩存的字段使用方法很簡單，只需要右鍵選擇Guess headers即可。并且為了不給真實用戶造成困擾，可以開啟cache buster(緩存粉碎機)。
從服務器誘發被投毒的響應
我們確認了不會被緩存的輸入以后，我們就要看服務端是如何處理這個輸入的，如果可以動態反饋到響應中，就是我們能夠發動Web緩存投毒的關鍵。
得到被緩存的響應
我們的輸入可以被反饋到響應中還不夠，還得能夠生成緩存，這樣才可以真正地將惡意payload落地。所以我們為此還是要不斷調試才能成功找到生成投毒緩存的操作。
基于緩存設計缺陷的Web緩存投毒攻擊
使用Web緩存投毒發動XSS攻擊
因為XSS攻擊也是有一部分是輸入被反饋在響應中，所以Web緩存投毒當然也可以用來發動XSS攻擊。我們關注這樣一對請求和響應
GET /en?region=uk HTTP/1.1Host: innocent-website.comX-Forwarded-Host: innocent-website.co.uk HTTP/1.1 200 OKCache-Control: public"og:image" content="https://innocent-website.co.uk/cms/social.png" />
我們觀察到X-Forwarded-Host指定的URL會代替Host的值被反饋在響應中，并且X-Forwarded-Host是不會被緩存的字段，但是Host和請求行是緩存鍵。所以所有Host為innocent-website.com的用戶請求/en?region=uk都會接收到被投毒的響應，像這樣
GET /en?region=uk HTTP/1.1Host: innocent-website.comX-Forwarded-Host: a.">alert(1)" HTTP/1.1 200 OKCache-Control: public"og:image" content="https://a."><script>alert(1)script>"/cms/social.png" />
當然了，alert只是彈窗驗證而已，攻擊者可以構造更復雜的XSS payload獲取更多的東西。
使用Web緩存投毒發動不安全的資源導入
有的應用程序會導入Host指定服務器的某個資源，比如JS資源，但是如果我們像上面一樣通過X-Forwarded-Host代替Host進行導入，則可能導入同名但是內容為惡意payload的JS資源，例如
GET / HTTP/1.1Host: innocent-website.comX-Forwarded-Host: evil-user.netUser-Agent: Mozilla/5.0 Firefox/57.0 HTTP/1.1 200 OK<script src="https://evil-user.net/static/analytics.js">script>
配套靶場：使用不被緩存頭的Web緩存投毒
首先我們隨便設置一個查詢參數，然后隨便設置一個值，只是為了測試Web緩存
從上圖來看，現在是沒有產生Web緩存的，然后我們插入到X-Forwarded-Host字段會替換掉本應是Host字段的值，這樣就相當于resources/js/tracking.js這個文件是可以偽造的，然后我們再go一下看一下緩存之后是什么樣子的
好，我們現在看到Web緩存已經生成了，這樣，所有被識別為發出等效請求的用戶都會接收到這個響應，就會訪問到”中毒”后的網頁，模擬結束，現在我們到Exploit Server把payload寫入到這個同名文件下
然后隨便找一個靶場里面的帖子進去，抓包改包，把Exploit Server的域名插到X-Forwarded-Host字段下，然后重放幾次讓Web緩存生成
然后在瀏覽器訪問這個頁面，就能實現彈窗了，如果沒生效就再緩存一次就行
使用不被緩存Cookie的Web緩存投毒
像上面一樣，我們觀察這樣的請求
GET /blog/post.php?mobile=1 HTTP/1.1Host: innocent-website.comUser-Agent: Mozilla/5.0 Firefox/57.0Cookie: language=pl;Connection: close
我們看到應用程序通過Cookie中的language的值來調整網站的語言，當該請求生成響應后，等效請求的用戶收到的就是波蘭語(pl)的頁面了。當然了，這種攻擊方式比較少，因為很容易因為影響到正常用戶被發現。
配套靶場：使用不被緩存Cookie的Web緩存投毒
首先我們觀察一下請求與響應的關系
我們可以看到Cookie中的fehost字段被自動拼接到響應中的script節點下，那么我們可以修改這個字段的值實現XSS攻擊
我們可以看到現在Web緩存已經生成了，并且我們修改后的字段值也是直接拼接到響應里，為了防止直接插XSS語句不生效，我們在前后多加了一般的script標簽分別把前面后面的script標簽閉合掉，從而成功發動XSS
使用多重頭發動Web緩存投毒攻擊
如果我們想要發動更高級的攻擊可以操縱多個請求頭來實現，現在我們考慮這樣的一個情況，就是應用程序默認是使用HTTPS協議傳輸的，但是如果我們使用HTTP協議訪問會自動觸發一個指向Host的重定向，但是我們可以通過X-Forwarded-Host代替Host的值重定向到惡意域，像這樣
GET /random HTTP/1.1Host: innocent-site.comX-Forwarded-Proto: http HTTP/1.1 301 moved permanentlyLocation: https://innocent-site.com/random
配套靶場：使用多重頭的Web緩存投毒
首先我們還是把HTTP History中的首頁的那個包發到Repeater里面，隨便加一個X-Forwarded-Host，Go一下，發現并沒有什么變化，而且/resources/js/tracking.js變成了相對路徑，那么我們再觀察一下是相對于誰呢？那么我們就想辦法讓頁面重定向，這就需要X-Forwarded-Scheme字段了，這個字段作用和X-Forwarded-Proto的效果是一樣的，如果請求方法是這個方法指定的則會重定向到用HTTPS請求主機名
我們發現當同時有X-Forwarded-Host和X-Forwarded-Scheme兩個字段的時候，就會有組合效果，因為請求方法為HTTP，則會重定向HTTPS流去請求主機名，然后這時候我們已經將主機名轉為我們指定的主機名，這樣它的相對路徑就可以生效了，我們先去Exploit Server構造Payload
然后我們在Repeater里面抓包改包，讓服務器產生Web緩存
我們可以看到重定向成功了，會跳轉到Exploit Server下的/resources/js/tracking.js
利用暴露大量信息的響應
有時，網站會泄露大量有關自身及其行為的信息，從而使自己更容易遭受Web緩存投毒攻擊。### Cache-control指令 有的時候響應會暴露緩存有效期等敏感信息，例如
HTTP/1.1 200 OKVia: 1.1 varnish-v4Age: 174Cache-Control: public, max-age=1800
有效期可以幫助我們去計算時間從而達到某種惡意目的。### Vary頭 Vary頭指定了一些可以被視為緩存鍵的字段列表，常見的如User-Agent頭，應用程序通過其可以僅向指定用戶群投放響應，也可以利用這個特點向特定用戶群發動Web緩存投毒攻擊。
配套靶場：使用未知請求頭的定向Web緩存投毒
找到隱藏字段X-Host，然后像之前那樣生成Web緩存，直接放生成緩存的結果
然后我們發現與之前的不同是User-Agent也是緩存鍵，所以我們還要去留言板釣他們的User-Agent
進到Exploit Server查收釣到的User-Agent，然后再結合剛才的那個生成新的Web緩存
使用Web緩存投毒發動基于DOM的漏洞攻擊
不僅可以通過Web緩存投毒導入惡意JS文件，還可以導入惡意的JSON字符串，例如
{"someProperty" : ""}
如果這條payload被傳遞到惡意的sink就可能觸發基于DOM的漏洞，如果想要讓網站加載惡意JSON就需要CORS授權允許跨站，例如
HTTP/1.1 200 OKContent-Type: application/jsonAccess-Control-Allow-Origin: *
{ "malicious json" : "malicious json"}
配套靶場：在嚴格可緩存性標準下使用Web緩存投毒發動基于DOM的漏洞攻擊
首先我們還是，默認使用Param Miner掃到可偽造字段X-Forwarded-Host。然后我們把首頁放到Repeater里看一下有沒有什么新東西
這些應該都是json的東西，大概的行為就是以data.host下的/resources/json/geolocate.json為參數執行initGeoLocate函數，然后我們再追蹤一下這個geolocate.js和geolocate.json
從圖上來看，geolocate.js會把j.country變量直接拼接進來，所以我們看一下這個country變量在哪，應該是在geolocate.json文件里面
那么我們就需要在Exploit Server中偽造屬于我們的geolocate.json文件，只是country的值換成xss語句
好的，然后我們就可以生成Web緩存了
刷新首頁成功加載我們自己的geolocate.json
注：掃到字段以后要把Param Miner的cachebuster都關了，不然永遠也不會生成緩存
Web緩存投毒鏈
如果將我們學過的幾種漏洞與Web緩存投毒結合起來，可以發動更高級的攻擊。下面我們直接通過一道靶場來深入理解。
Web緩存投毒鏈
我們識別到兩個可用來投毒的字段：X-Forwarded-Host、X-Original-URL，然后分析一下/resources/js/translations.js這個文件，看一下initTranslations()這個函數是怎么運作的
首先我們來看一下提取現在網頁的語言的函數
大概是這么一個流程，然后是翻譯函數，因為只翻譯首頁，所以所謂的翻譯就是一對一的替換，然后我們留意一下紅框部分，就是說除了英語其他的都會執行翻譯，也就是說除了英語以外的我們都能用來插入DOM-XSS語句，考慮到亂碼問題，我們選擇en-gb這個，雖然也是英語，但是因為代碼里嚴格匹配en，所以這個也是可以用來插入的，而且也不用考慮亂碼的問題，現在我們去Exploit Server寫入DOM-XSS語句進去
然后我們需要抓取/?localized=1這個包，因為你選擇翻譯的時候會請求這個頁面，然后修改X-Forwarded-Host字段為Exploit Server的，并產生Web緩存
但是這是翻譯頁面，我們要怎樣才能讓用戶首先進到的就是我們的翻譯頁面呢，那就是在首頁加入一個X-Original-URL字段指向翻譯頁面，這樣訪問首頁的人就都會被重定向到這個頁面了
因為需要生成兩個Web緩存并且需要在靶場訪問的時候同時在生效中，所以需要多試幾次
基于緩存實現缺陷的Web緩存投毒攻擊
緩存鍵缺陷
傳統的攻擊經常通過將payload注入查詢字符串實現，但是請求行是緩存鍵，這就導致不可能會有用戶發出等效請求，也就接收不到投毒響應緩存，但是如果有CDN的話，他們會將緩存鍵內容進行某些處理之后再存入緩存，例如
- 排除查詢字符串
- 過濾掉特定的查詢參數
- 規范緩存鍵中的輸入
尤其是前兩條，即使我們注入payload到查詢字符串或參數中，用戶也可能收到被投毒的響應緩存。
識別合適的緩存斷言
首先我們要識別合適的緩存斷言以測試緩存的過程。我們需要知道我們接收到的響應是來自緩存還是服務器，比如從以下地方可以得到反饋
- 可準確告知是否為緩存的HTTP頭
- 動態的可觀察變化的內容
- 不同的響應時間
有的時候應用程序會使用第三方的緩存組件，此時可以通過查閱相關文檔的方式得知緩存的過程。例如，基于Akamai的網站可能支持Pragma：akamai-x-get-cache-key，它可以在響應標頭中顯示緩存鍵。
GET /?param=1 HTTP/1.1Host: innocent-website.comPragma: akamai-x-get-cache-key HTTP/1.1 200 OKX-Cache-Key: innocent-website.com/?param=1
探測緩存鍵的處理過程
我們應該還要觀察緩存是否對緩存鍵有其他的處理。比如剔除Host中的端口號等。下面我們來關注這樣一對請求和響應。它會動態將Host值拼接到Location中
GET / HTTP/1.1Host: vulnerable-website.com HTTP/1.1 302 Moved PermanentlyLocation: https://vulnerable-website.com/enCache-Status: miss
然后我們在Host中隨便加入一個端口，觀察一下響應
GET / HTTP/1.1Host: vulnerable-website.com:1337 HTTP/1.1 302 Moved PermanentlyLocation: https://vulnerable-website.com:1337/enCache-Status: miss
我們再去掉端口號重新發送請求
GET / HTTP/1.1Host: vulnerable-website.com HTTP/1.1 302 Moved PermanentlyLocation: https://vulnerable-website.com:1337/enCache-Status: hit
發現已經生成緩存，但是緩存是我們加了端口號發出時的響應版本。這就說明端口號是不會加入緩存鍵中的。
識別可利用的漏洞
講了這么多，其實Web緩存投毒的危害程度完全取決于其能夠用來發動的攻擊，常見的有像反射型XSS、開放重定向等客戶端漏洞。并且Web緩存投毒不需要用戶點擊任何鏈接，可能在發出正常的請求時也會接收到被投毒的響應緩存。
緩存鍵缺陷的利用
不被緩存的端口號
前面我們介紹過，緩存鍵有時候可能不會只會緩存域名或主機名而不緩存端口號。所以我們可以利用這個特點發動如DDOS(向任意端口號發出大量請求)、XSS(在端口號位置插入payload)等攻擊。
不被緩存的查詢字符串
探測不被緩存的查詢字符串
有的應用程序并不會在響應中告知是否產生緩存。而且如果查詢字符串不是緩存鍵的話，即使不同的查詢字符串也會得到相同的響應緩存。那么我們可以在其他請求頭中下手，例如加在Accept-Encoding字段中
Accept-Encoding: gzip, deflate, cachebusterAccept: */*, text/cachebusterCookie: cachebuster=1Origin: https://cachebuster.vulnerable-website.com
其實也可以在Param Miner開啟動態的緩存粉碎機(cachebuster)。還有一種辦法就是修改不同的路徑，但是仍然可以的到相同的響應緩存。例如
Apache: GET //Nginx: GET /%2FPHP: GET /index.php/xyz.NET GET /(A(xyz)/
利用不被緩存的查詢字符串
查詢字符串不會被緩存可能會擴大XSS攻擊面，因為附有XSS payload的查詢字符串的請求在緩存看來與普通請求無異。但是普通用戶可能就會接收到被投毒的響應緩存。
配套靶場：通過不被緩存的查詢字符串的Web緩存響應
這一關考察就是常規的web緩存投毒，這一關并沒有對查詢字符串進行綁定，所以同一個路徑下即識別為等效頁面即投放緩存，那么我們直接在URL里面投毒
響應中的Age字段可以告訴我們它的緩存已經生效多長時間了，這一關設定的是35秒后重新緩存，可以作為我們投毒的一個信號標，于是我們看一下這時候訪問根目錄的響應是怎樣的
我們得到的就是投毒后的緩存，這時訪問首頁的人都會接收到投毒的緩存
不被緩存的查詢參數
有的時候緩存僅將某幾個查詢參數排除在緩存鍵中，例如utm_content 等utm參數。但是這種攻擊方式會因為參數不太會被專門處理而沒有那么大的危害。但是如果有功能點可以處理整個URL則可能會有轉機。
配套靶場：通過不被緩存的查詢參數的Web緩存響應
這一關考點是它只有某些查詢參數不會作為緩存鍵，我們掃到utm_content這個查詢參數不是緩存鍵，所以我們可以用這個參數實現Web緩存投毒
等到重新生成Web緩存的時候，成功通關
緩存參數隱藏
有的時候因為解析差異，可以將某些本來是緩存鍵的查詢參數隱藏到非緩存鍵中。例如查詢字符串中通過與(&)區分各個參數，通過問號(?)識別查詢參數的開始。但是如果有多個問號，就會以第一個問號作為查詢參數的開始，例如
GET /?example=123?excluded_param=bad-stuff-here
這時，excluded_param就不會被作為緩存鍵處理。
利用參數解析差異
有的應用程序有一些特殊的查詢參數解析規則，比如Ruby on Rails框架將與(&)和分號 (;)作為參數分隔符。但是如果緩存不支持這樣解析參數，就會造成差異。例如
GET /?keyed_param=abc&excluded_param=123;keyed_param=bad-stuff-here
如上所示，keyed_param就會被視為緩存鍵，而excluded_param不會，而且只會被緩存解析成兩個參數
keyed_param=abcexcluded_param=123;keyed_param=bad-stuff-here
而被Ruby on Rails解析成三個參數
keyed_param=abcexcluded_param=123keyed_param=bad-stuff-here
此時keyed_param的值就會被覆蓋為bad-stuff-here，也會得到由這個值生成的響應，但是在緩存看來只要該參數值為abc的都會被視為該響應的等效請求。利用這種特點可以發動JSONP攻擊，它會將回調函數名附在查詢參數中，例如
GET /jsonp?callback=innocentFunction
我們可以利用上面的特點替換成我們指定的函數名。
配套靶場：參數差異
這一關主要是考察緩存與后臺對URL參數的處理方式不同導致的Web緩存投毒，通過掃描得知utm_content是可偽裝的緩存鍵，后臺將(&)和(;)識別為分界符，這樣就可以利用這種差異覆蓋回調參數的值為我們指定的函數
這樣訪問首頁的人就也會接收到我們的投毒緩存了
利用支持fat GET請求
有的時候請求方法并不是緩存鍵，這時候如果支持fat GET請求方法就也可以用來進行Web緩存投毒。fat GET請求很特殊，擁有URL查詢參數和正文參數，而只有請求行是緩存鍵，而且應用程序會從正文參數獲取參數值，例如我們構造這樣的請求
GET /?param=innocent HTTP/1.1…param=bad-stuff-here
如果X-HTTP-Method-Override頭也是非緩存鍵，我們可以構造偽POST請求來攻擊，例如
GET /?param=innocent HTTP/1.1Host: innocent-website.comX-HTTP-Method-Override: POST…param=bad-stuff-here
配套靶場：通過fat GET請求的Web緩存響應
這一關考察的是HTTP方法不是緩存鍵，這樣我們就可以把覆蓋的值插入到正文參數中
這樣的話在緩存看來直接訪問首頁的人會被識別成等效頁面而接收到緩存副本，在后臺看來會識別成POST方法而讀取覆蓋之后的callback參數的值而返回投毒響應，這樣訪問首頁的人就會接收到投毒緩存了
利用資源導入的動態內容
有的時候雖然看上去是導入靜態文件，但是也可以向查詢字符串中注入惡意payload構造某些攻擊，例如
GET /style.css?excluded_param=123);@import… HTTP/1.1 HTTP/1.1 200 OK…@import url(/site/home/index.part1.8a6715a2.css?excluded_param=123);@import…
甚至可以注入XSS payload
GET /style.css?excluded_param=alert(1)%0A{}*{color:red;} HTTP/1.1
HTTP/1.1 200 OKContent-Type: text/html…This request was blocked due to…alert(1){}*{color:red;}
標準化的緩存鍵
有的時候對緩存鍵的規范化也會觸發Web緩存投毒，比如緩存服務器會統一做URL解碼，所以下面兩條被認為是等效的
GET /example?param=">GET /example?param=%22%3e%3ctest%3e
這就導致原本無法成功利用的XSS攻擊可以重新成功利用
配套靶場：URL標準化
這一關考察的是利用緩存與后臺對編碼的處理方式不同，瀏覽器會做URL編碼，但是到后臺不會解碼導致無法XSS攻擊，但是緩存會對編碼做標準化，這樣我們訪問一個不存在的路徑，這樣響應就是經過緩存標準化的結果
這樣我們在Web緩存還在生效的時候給受害者投放帶payload的URL就能重新成功攻擊
緩存鍵注入
我們還可以利用雙下劃線(__)分隔不同的字段的方式讓兩個不同的請求識別為等效的，例如
GET /path?param=123 HTTP/1.1Origin: '-alert(1)-'__ HTTP/1.1 200 OKX-Cache-Key: /path?param=123__Origin='-alert(1)-'__ <script>…'-alert(1)-'…script>
它和下面的一對請求和響應是等效的
GET /path?param=123__Origin='-alert(1)-'__ HTTP/1.1 HTTP/1.1 200 OKX-Cache-Key: /path?param=123__Origin='-alert(1)-'__X-Cache: hit <script>…'-alert(1)-'…script>
配套靶場：緩存鍵注入
我們需要構造一條Web緩存投毒鏈，因為是一層一層跳轉的，所以我們要從里到外的順序構造Web緩存投毒，因為訪問首頁會自動跳轉到/login，所以我們需要先在/js/localize.js然后在/login構造
這里涉及到多個知識點，第一個就是CRLF注入，就是CR是回車符，LF是換行符，CRLF組合在一起就是相當于另起一行，這樣我們就可以在一個HTTP頭部字段里面注入多個字段，從圖中的框框來看，確實實現了這種效果，而CRLFCRLF即表示頭部的結束，主體的開始，我們就可以把xss語句插入到里面實現XSS攻擊，為了能將請求的內容注入到響應中，我們需要開啟cors，即將cors=0改為cors=1，并將payload寫入Origin字段實施注入，然后我們需要產生Web緩存那就需要引入utm_content字段，經過測試，utm_content和Origin的值是可以任意字符串的，但是URL里面的x就只能是x=1，這個x=1是開啟緩存功能的開關，然后構造/login頁面
因為我們已經利用/js/localize.js構造Web緩存，然后在/login的URL里面直接構造這樣的payload會被緩存識別為等效頁面而投放中毒緩存
對內部緩存投毒
前面講的都是從外部構造各種稀奇古怪的攻擊方式。有的應用程序不會緩存整個響應，而是使用緩存片段，這讓Web緩存投毒的攻擊面達到最大，因為可能所有用戶都可能接收到拼接了被投毒的緩存片段的響應。在這種攻擊方式中，緩存鍵的概念已不使用，我們甚至只需要簡單地修改Host頭即可
如何識別對內部緩存投毒
如果我們一系列的輸入中最開始的輸入和最后的輸入出現在了同一個響應中則說明當前應用程序采用緩存片段技術。
配套靶場：對內部緩存投毒
這一關講的是對內部緩存投毒，就是將一整個緩存換成多個可重用的片段，有的時候你的一個請求產生的緩存會流向其他頁面，然后我們將param miner中的add dynamic cache-buster打開，然后在X-Forwarded-Host字段寫入Exploit Server的地址以重定向到我們的投毒頁面
多重放幾次，直到最后一個URL被替換為Exploit Server的地址
安全地測試內部緩存
因為測試內部緩存可能會導致所有用戶都收到惡意的緩存片段，所以在發送每一條測試請求之前都要考慮后果。盡量不要使用類似帶外等技術發送跨域請求。
如何緩解Web緩存投毒漏洞？
Web緩存投毒漏洞非常隱蔽，決定開啟緩存功能的應用程序一定要進行嚴格的安全防護，盡量使用靜態響應及對導入的資源進行校驗。盡可能修復客戶端漏洞以防止被進一步利用。應禁止模棱兩可的請求方法，如fat Get方法。應盡可能禁用不需要的一切HTTP頭字段，無論多罕見。
總結
以上就是梨子帶你刷burpsuite官方網絡安全學院靶場(練兵場)系列之高級漏洞篇 – Web緩存投毒專題的全部內容啦，本專題主要講了Web緩存投毒的形成原理，以及從緩存設計與實現缺陷兩個大角度介紹了各種可能的漏洞利用方式，最后簡單介紹了防護手段，該專題的東西很多很復雜，需要大家耐心花點時間消化哦，感興趣的同學可以在評論區進行討論，嘻嘻嘻。
