python - 如何在Flask中安全地獲取具有代理的用戶IP地址？

問題

這里的問題不是ProxyFix本身會導致用戶訪問您的系統，而是ProxyFix將采用曾經最可靠的信息並用可能不可靠的信息替換它。

對於初學者，當您不使用ProxyFix時，很可能從TCP數據包中的源IP地址檢索REMOTE_ADDR屬性。 雖然並非不可能，但TCP數據包中的源IP地址很難欺騙。 因此，如果您需要一種可靠的方法來檢索用戶的IP地址，REMOTE_ADDR是一種很好的方法。 在大多數情況下，當你發出request.remote_addr時，你可以依靠它為你提供准確的東西。

當然，問題是在反向代理情況下，TCP連接不是來自最終用戶; 相反，最終用戶與反向代理建立TCP連接，然后反向代理與您的Web應用程序建立第二個TCP連接。 因此，應用中的request.remote_addr將具有反向代理的IP地址，而不是原始用戶的IP地址。

潛在的解決方案

ProxyFix應該解決這個問題，這樣你就可以使request.remote_addr擁有用戶的IP地址而不是代理。 它通過查看遠程代理（如Apache和Nginx）添加到HTTP標頭（ X-Forwarded-For ）並使用其在那里找到的用戶IP地址的典型HTTP標頭來實現此目的。 請注意，Cloudflare使用不同的HTTP標頭，因此ProxyFix可能無法幫助您; 您需要編寫自己的中間件實現來獲取request.remote_addr以使用原始客戶端的IP地址。 但是，在本答復的其余部分中，我將繼續將該修復稱為“ProxyFix”。

然而，該解決方案存在問題。 問題是雖然TCP標頭最可靠，但HTTP標頭不是; 如果用戶可以繞過您的反向代理並將數據直接發送到服務器，他們可以在HTTP標頭中放置他們想要的任何內容。 例如，他們可以使HTTP頭中的IP地址成為其他人的IP地址！ 如果使用IP地址進行身份驗證，則用戶可以欺騙該身份驗證機制。 如果將IP地址存儲在數據庫中，然后將其在應用程序中以HTML格式顯示給另一個用戶，則用戶可能會將SQL或Javascript注入到標頭中，從而可能導致SQL注入或XSS漏洞。

所以，總結一下; ProxyFix采用一種已知的最安全的解決方案，從TCP數據包中檢索用戶的IP地址，並使用解析易受欺騙的HTTP標頭的非常安全的解決方案將其切換。

因此，在反向代理情況下僅使用ProxyFix的建議意味着：如果您接受來自非代理的位置的連接，請不要使用此方法。 這通常意味着讓反向代理（如Nginx或Apache）處理所有傳入流量，並讓您的應用程序在防火牆后面實際使用ProxyFix。

您還應該閱讀這篇文章，其中解釋了ProxyFix過去是如何被破壞的（盡管現已修復）。 這也將解釋ProxyFix如何工作，並為您提供有關如何設置num_proxies參數的想法。

更好的解決方案

假設您的用戶位於A點，他們將請求發送到Cloudflare（B），最終將請求發送到您的最終應用程序（C點）。 Cloudflare將在CF-Connecting-IP header發送A的IP地址。

如上所述，如果用戶找到指向C的IP地址，他們可以直接向C點發送特制的HTTP請求，其中包括他們想要的任何頭信息。 ProxyFix將使用其邏輯來確定HTTP頭中的IP地址，如果您依賴該值，那么這當然是有問題的。

因此，您可能希望查看類似mod_cloudflare的內容，它允許您直接在Apache mod中執行這些代理修復，但僅限於HTTP連接來自Cloudflare IP地址（由TCP IP源定義）。 您也可以只接受來自Cloudflare的連接。 有關詳細信息，請參閱如何將原始訪問者IP還原到我的服務器日志，並幫助其他服務器（如Nginx）執行此操作。

這應該給你一個開始。 但是，請記住，您仍然不是“安全”：您只關閉了一個可能的攻擊向量，並且該攻擊向量假定攻擊者知道您的實際應用程序的IP地址。 在這種情況下，惡意用戶可能會嘗試使用欺騙性Cloudflare IP地址進行TCP攻擊，盡管這非常困難。 更有可能的是，如果他們想要造成嚴重破壞，他們只會DDOS你的源服務器，因為他們繞過了Cloudflare。 因此，在保護您的應用程序時還需要考慮更多的事情。 希望這有助於您了解如何使一個部分更安全。