Web緩存投毒實戰（四）

Open Graph的劫持

在另一個站點上，非緩存鍵的輸入專門影響Open Graph URL：

Open Graph是一種由Facebook創建的協議，允許網站所有者控制他們在社交媒體上分享的內容。我們劫持的og：url參數有效地覆蓋了分享的URL，因此任何分享被投毒的頁面的人實際上最終都會分享我們指定的內容。

您可能已經注意到，應用程序設置了"Cache-Control：private"，而Cloudflare拒絕緩存此類響應。幸運的是，網站上的其他頁面明確啟用了緩存：

這裡的"CF-Cache-Status"協議頭是Cloudflare正在考慮緩存此響應的指示，但儘管如此，響應從未實際緩存過。我推測Cloudflare拒絕緩存這個可能與session_id cookie有關，並且使用該cookie重試：

最終我得到了緩存的響應，後來發現我可以跳過猜測並閱讀Cloudflare的緩存文檔。

儘管緩存響應，但「分享」結果仍然沒有投毒; Facebook顯然沒有達到我投毒特定Cloudflare緩存的要求。為了確定我需要投毒哪個緩存，我利用了所有Cloudflare站點上的一個有用的調試功能 —— /cdn-cgi/trace：

在這裡，colo = AMS行顯示Facebook已經通過Amsterdam的緩存訪問了waf.party。目標網站是通過 Atlanta訪問的，所以我在那裡租了2美元/月的VPS並再次嘗試投毒：

在此之後，任何試圖在其網站上共享各種頁面的人最終都會分享我選擇的內容。這是一個經過修改的攻擊視頻。

本地路由投毒

到目前為止，我們已經看到基於cookie的語言劫持，並且使用各種協議頭的攻擊去覆蓋主機。在這一點的研究上，我還發現了一些使用奇怪的非標準協議頭的變體，例如"translate"，"bucket"和"path_info"，並且我懷疑遺漏了許多其他協議頭。在我通過下載並搜索GitHub上的前20,000個PHP項目以獲取協議頭名稱來擴展協議頭wordlist之後，我的下一個重大進展來了。

這揭示了協議頭X-Original-URL和X-Rewrite-URL，它覆蓋了請求的路徑。我首先注意到的是它們會影響目標運行Drupal，並且通過挖掘Drupal的代碼發現，對此協議頭的支持來自流行的PHP框架Symfony，它又是從Zend獲取的代碼。最終結果是大量的PHP應用程序無意中支持這些頭文件。在我們嘗試使用這些協議頭進行緩存投毒之前，我應該指出它們也非常適合繞過WAF和安全規則：

如果應用程序使用緩存，為把協議頭混淆到錯誤的頁面，就有可能濫用這些協議頭。例如，此請求的緩存鍵為/education?x=y，但從/gambling?x=y檢索內容：

最終結果是，在發送此請求後，任何試圖訪問Unity for Education頁面的人都會感到驚訝：

改變頁面的能力看上去更有趣些，但它也許能帶來更大的利益。

英文原文：https://portswigger.net/blog/practical-web-cache-poisoning
譯者：盈韜

未完，接本日推送第五篇

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！