本文將介紹攻擊者是利用漏洞發起HTTP Desync攻擊的，目標都是一些知名網站，這些漏洞透過劫持客戶端、木馬化快取、還有竊取憑據來發起攻擊。
對Netflix的HTTP Desync攻擊
由於HTTP/2的資料幀長度欄位，Content-Length標頭是不需要的。然而，HTTP/2 RFC宣告該標頭是允許的，只要它是正確的。Netflix使用了一個無需驗證內容長度就執行HTTP降級的前端。研究人員發出了以下HTTP/2請求：
在前端將此請求降級為HTTP/1。1後，它到達後端，看起來像這樣：
由於 Content-Length 不正確，後端提前停止處理請求，橙色資料被視為另一個請求的開始。這使研究人員能夠為下一個請求新增任意字首，而不管它是誰傳送的。
受害者的請求重定向到研究人員的伺服器 02。rs：
透過重定向 JavaScript 包含，研究人員可以執行惡意 JavaScript 來破壞 Netflix 帳戶，並竊取密碼和信用卡號。透過迴圈執行這種攻擊，研究人員可以在沒有使用者互動的情況下逐漸攻擊網站的所有活躍使用者，這種嚴重程度是請求走私的典型表現。
針對Application Load Balancer（簡稱ALB）的HTTP Desync攻擊
接下來，讓研究人員看看一個簡單的 H2。TE HTTP Desync。 RFC 狀態為“任何包含特定於連線的標頭欄位的訊息都必須被視為格式錯誤。”
一個特定於連線的標頭欄位是Transfer-Encoding。Amazon Web Services （AWS）的應用ALB未能遵守此行，並接受包含Transfer-Encoding的請求。這意味著攻擊者可以透過 H2。TE HTTP Desync來利用幾乎所有使用它的網站。
其中一個易受攻擊的網站是Verizon的執法入口網站，位於id。b2b。oath。com。研究人員使用以下請求利用了它：
前端將此請求進行了降級：
降級後，“transfer-encoding： chunked”標標頭檔案優先於前端插入的內容長度。這使得後端提前停止解析請求正文，並使研究人員能夠將任意使用者重定向到在psres。net的網站。
H2。TE透過請求標頭注入
由於HTTP/1是明文協議，所以不可能在某些地方放置某些解析關鍵字元。例如，你不能在標標頭檔案值中放入\r\n序列，這樣你就只會終止標標頭檔案。
在HTTP/2中壓縮標頭的方式，使你可以把任意字元放在任意位置。一個易受攻擊的實現是 Netlify CDN，它在基於它的每個網站上啟用了 H2。TE HTTP Desync攻擊，包括 Firefox 的 start。mozilla。org 起始頁面。研究人員製作了一個在標頭值中使用 ‘\r\n’ 的漏洞：
在降級過程中，\r\n觸發了一個請求標頭注入漏洞，引入了一個名為Transfer-Encoding： chunked額外標頭。
這觸發了 H2。TE HTTP Desync，其字首旨在讓受害者從自己的 Netlify 域接收惡意內容。由於 Netlify 的快取設定，有害響應將被儲存並持續提供給任何其他試圖訪問相同 URL 的使用者。這樣攻擊者就可以完全控制 Netlify CDN 上面每個網站的每個頁面。
H2。TE透過標頭名稱注入
Atlassian嘗試不允許在標頭值中使用換行符，但未能過濾標頭名稱。這很容易被攻擊者利用，因為伺服器允許在標頭名稱中使用冒號，這在HTTP/1。1中是不可能實現的。
最初的修復程式也沒有過濾偽標頭，導致請求行注入漏洞。利用這些很簡單，只要視覺化注入發生的位置，並確保得到的HTTP/1。1請求有一個有效的請求行：
修復程式的最後一個漏洞是一個典型的錯誤，即阻止‘ r\n’，而不是阻止‘ n’本身，後者幾乎總是被利用。
隱匿隧道攻擊
大多數前端很可以透過任何連線傳送任何請求，從而實現跨使用者攻擊。然而，你會發現你的字首只會影響來自你自己 IP 的請求。發生這種情況是因為前端為每個客戶端 IP 使用與後端的單獨連線。這有點麻煩，但你通常可以透過快取攻擊間接攻擊其他使用者來解決該問題。
其他一些前端在來自客戶端的連線和到後端的連線之間強制執行一對一的關係。這是一個更嚴格的限制，但是常規的快取攻擊和內部標頭洩漏技術仍然適用。
當前端選擇重用與後端的連線時，攻擊就會變得非常具有挑戰性。此時傳送直接影響後續請求的請求是不可能的：
首先是確認漏洞，你可以透過傳送一系列請求並檢視早期請求是否影響後期請求來確認常規請求是否走私漏洞。不幸的是，這種技術總是無法確認請求隧道，因此很容易將漏洞誤認為是誤報。
研究人員需要一種新的確認技術，即簡單地走私一個完整的請求，然後看看你是否得到兩個響應：
假如你在HTTP/2響應正文中看到HTTP/1標頭，你就會發現自己是一個HTTP Desync：
前端伺服器通常使用後端響應上的 Content-Length 來決定從套接字讀取多少位元組。這意味著即使你可以向後端發出兩個請求，並從中觸發兩個響應，前端也只將第一個不太有趣的響應傳遞給你。
在以下示例中，由於突出顯示了 Content-Length，以橙色顯示的403響應從未傳遞給使用者：
終端返回的響應太大，導致Burp Repeater稍微滯後，所以研究人員決定將研究人員的方法從POST切換到HEAD來縮短它。這實際上是要求伺服器返回響應標頭，但省略了響應正文：
果然，這導致後端只服務響應標頭，包括未傳播正文的Content-Length標頭！這使得前端過度讀取並提供對第二個走私請求的部分響應：
走私無效請求也會讓後端關閉連線，避免意外響應佇列攻擊的可能性。請注意，如果目標僅易受隧道攻擊，則響應佇列攻擊是不可能的，因此你無需擔心。有時，當 HEAD 失敗時，其他方法（如 OPTIONS、POST 或 GET）會起作用。研究人員已經將這種技術新增到HTTP Request Smuggler作為檢測方法。
請求隧道使你可以使用前端完全未處理的請求到達後端，最明顯的利用路徑是利用它繞過諸如路徑限制之類的前端安全規則。但是，你經常會發現沒有任何相關規則可以繞過。幸運的是，還有第二種選擇。
前端伺服器通常會注入用於關鍵功能的內部標頭，例如指定使用者登入的身份。由於前端檢測並重寫它們，直接利用這些標頭的嘗試通常會失敗。你可以使用請求隧道繞過此重寫併成功走私內部標頭。
不過有一個問題，攻擊者通常看不到內部標頭，並且很難利用不知名的標頭。只要伺服器的內部標頭在Param Miner的wordlist中，並且在伺服器的響應中引起可見的差異，Param Miner就應該檢測到它。
內部標頭洩漏
不存在於 Param Miner 的靜態詞表中或在網站流量中洩露的自定義內部標頭可能會逃避檢測。常規請求走私可用於使伺服器將其內部標頭洩露給攻擊者，但這種方法不適用於請求隧道。如果你可以透過 HTTP/2 在標頭中注入換行符，那麼還有另一種發現內部標頭的方法。經典的HTTP Desync攻擊依賴於讓兩個伺服器對請求正文的結束位置產生分歧，但是使用換行符，研究人員可以讓伺服器對正文的開始位置產生分歧！
為了獲得bitbucket使用的內部標頭，研究人員發出了以下請求：
在降級之後，它看起來是這樣的：
可以看到，前端認為‘s=cow’是標標頭檔案的一部分，所以在此之後插入內部標頭。這意味著後端最終將內部標頭視為研究人員傳送到 Wordpress 搜尋功能的 ‘s’ POST 引數的一部分，並將它們反射回來：
在 bitbucket。org 上訪問不同的路徑會導致研究人員的請求被路由到不同的後端，並洩漏不同的標頭：
你也許可以使用隧道來進行更強大的各種 Web 快取攻擊。此時你需要透過 H2。X desync 獲得請求隧道，HEAD 技術有效，並且存在快取。這將允許你使用 HEAD 透過混合和匹配任意標頭和正文建立的有害響應來攻擊快取。
經過一番挖掘，研究人員發現獲取 /wp-admin 會觸發一個重定向，該重定向反映了 Location 標頭內的使用者輸入，而不對其進行編碼。就其本身而言，這是完全無害的 - Location 標頭不需要 HTML 編碼。然而，透過將它與來自 /blog/404 的響應標頭配對，研究人員可以欺騙瀏覽器來呈現它，並執行任意的JavaScript：
HTTP / 2漏洞利用原語
接下來，讓研究人員看看一些HTTP/2利用原語，本節不提供完整的案例研究。
模糊性和 HTTP/2
在HTTP/1中，重複標頭對於各種攻擊都有用，但不可能傳送具有多個方法或路徑的請求。HTTP/2決定用偽headers替換請求行，這意味著這現在是可能的。研究人員觀察到接受多個 ：path 標頭的真實伺服器，並且伺服器實現在它們處理的 ：path 中不一致：
此外，儘管 HTTP/2 引入了 ：authority 標頭來替換 Host 標頭，但 Host 標頭在技術上仍然是允許的。事實上，據研究人員所知，兩者都是可選的。這為 Host-header 攻擊創造了充足的機會，例如：
URL字首注入
HTTP/2的另一個不能忽略的特性是：scheme偽標頭，這個值意味著‘http’或‘https’，但它支援任意位元組。
包括 Netlify 在內的一些系統使用它來構建 URL，而不執行任何驗證。這使你可以覆蓋路徑，並在某些情況下執行快取攻擊：
其他人使用該方案構建請求路由到的 URL，從而建立 SSRF 漏洞。
與本文中使用的其他技術不同，即使目標沒有進行 HTTP/2 降級，這些漏洞也會起作用。
標頭名稱Split
你會發現有些伺服器不允許你在標頭名稱中使用換行符，但允許使用冒號。由於在降級過程中末尾會附加冒號，這很少啟用完全HTTP Desync：
它更適合 Host-header 攻擊，因為 Host 應該包含一個冒號，並且伺服器通常會忽略冒號之後的所有內容：
請求行(Request-Line) 注入
研究人員確實找到了一臺伺服器，其中標頭名稱Split啟用了HTTP Desync。在測試中，漏洞消失了，伺服器橫幅報告說他們已經更新了他們的資訊 Apache 前端。為了追蹤這個漏洞，研究人員在本地安裝了舊版本的Apache。不過研究人員無法複製這個漏洞。
Apache 的 mod_proxy 允許在 ：method 使用空格，從而啟用請求行注入。如果後端伺服器容忍請求行末尾的垃圾，這可以讓你繞過阻止規則：
逃避子資料夾：
標頭篡改
HTTP/1。1曾經有一個功能叫做行摺疊，你可以在標頭值後面加上一個空格，隨後的資料就會被摺疊起來。
下面是一個正常傳送的相同請求：
使用性轉移：
該功能後來被棄用，但許多伺服器仍然支援它。
如果你發現一個網站的 HTTP/2 前端允許你傳送以空格開頭的標頭名稱，而後端支援換行，則你可以篡改其他標頭，包括內部標頭。這是研究人員篡改了內部標頭請求 ID 的示例，它是無害的，但在後端反映了有用的資訊：
許多前端不會對傳入的標標頭檔案進行排序，所以你會發現透過移動空格標頭，你可以篡改不同的內部和外部標標頭檔案。
關注私信回覆“資料”獲取安全學習思路PDF大綱
安全建議
如果你正在設定 Web 應用程式，千萬不要讓 HTTP/2 降級，這是上述這些漏洞得逞的根本原因。
