使用反向代理的主機頭攻擊
因此，我的任務是研究 Acunetix 網路安全掃描發現的問題。
以下是有關掃描的詳細資訊：
我還不能發布兩個以上的連結，因為我沒有足夠的聲譽，但是上述第一個連結上的骨架抄寫參考更詳細地介紹了該漏洞，並且似乎是該主題的主要來源。
建議的解決方法建議使用“虛擬”預設虛擬主機和應用程序，
SERVER_NAME而不是使用Host 標頭。這些建議在談論真正的原始伺服器時非常有用，但在您使用反向代理時就不那麼重要了。Acunetix 正在掃描的我們的網站設置為位於反向代理後面的應用程序伺服器。在我們的例子中，反向代理是 iPlanet，但我已經在 Apache 2.4.7 中確認了相同的行為
mod_proxy。以下是它的工作原理，以及它觸發 Acunetix 掃描的原因。當使用絕對 URI 發出請求時（如掃描器所做的那樣），根據 RFC 規範，伺服器意味著忽略 Host 標頭，而是使用絕對 URI 內的主機。這是我們看到的行為，因此選擇了正確的虛擬主機，即使 Host 標頭具有不正確/惡意的值。到現在為止還挺好。
當反向代理隨後將此請求傳遞給後端源伺服器時，就會出現問題。當它這樣做時，它將原始 Host 標頭與請求一起傳遞。如果 Host 標頭具有不正確或惡意的值，則會將其傳遞回源伺服器。如果源站沒有實現虛擬主機，則不需要驗證 Host 頭是否正確。
這樣做的結果是，在源 Web/應用程序伺服器上執行的任何嘗試使用Host 標頭值的應用程序都將使用惡意主機值。在這種情況下使用
SERVER_NAME是沒有用的，因為站點的伺服器名稱（或真實主機）不會被反向代理轉發，並且源伺服器仍然使用 Host 標頭值進行響應。在這裡使用UseCanonicalName和ServerName 指令也沒有用，因為您需要原始請求中的伺服器名稱，這可能是多個值。這種“攻擊”是在 2013 年發現的，但我找不到很多關於它的資訊，而不僅僅是從上述參考資料中重複了細節。這不是一個常見的問題，因為 HTTP 客戶端不會發送絕對 URI，除非它們正在與轉發代理伺服器通信。這意味著所有正常請求都將是相對 URI，然後這個問題就會消失（惡意主機標頭然後卡在反向代理上的“虛擬”或預設虛擬主機上）。
SERVER_NAME我確實創建了一個解決方法，即反向代理在將請求發送到後端之前主動將 Host 標頭設置為。這可行，但我擔心它是否可能是違反投注實踐/標準的解決方案。像這樣設置 Host 標頭會破壞什麼嗎？我們對此進行了頭腦風暴，但我想不出一個場景。明天我將打電話給 Oracle 以獲得他們的回饋。在我看來，這可能是一個邊緣案例，這只是我嘗試過的兩個 Web 伺服器產品的疏忽，但我無法想像某些事情會持續這麼長時間而沒有得到解決。我肯定錯過了什麼。
對不起，這麼長，但是，有什麼想法嗎？:) 這篇文章的“問題”部分是這樣的：
- 我上面的解決方法會是一個很好的解決方案還是會破壞事情？
- 這個問題有已知的解決方案嗎？
預設情況下，您的反向代理應該為您更正 Host: 標頭。它不這樣做是一個錯誤，應該向其開發人員報告。
當代理接收到請求目標的絕對形式的請求時，代理必須忽略接收到的主機頭欄位（如果有），而是將其替換為請求目標的主機資訊。轉發此類請求的代理必鬚根據接收到的請求目標生成新的主機欄位值，而不是轉發接收到的主機欄位值。
請注意，此 RFC 的先前版本 RFC 2616 沒有那麼具體。它只說：
HTTP/1.1 代理必須確保它轉發的任何請求消息都包含適當的主機頭欄位，該欄位標識代理正在請求的服務。
不能說您的代理的行為符合舊規範或新規範。
同時，您的解決方法很好，因為它引入了正確的行為。