http到https重定向的安全性

Question

我有一個100％https的網站，只能用作https。我的網站是一個運行在IIS 7.5上的asp.net mvc應用程序。

它在多個服務器上通過負載均衡器分配流量。

我不控制硬件。

對於http請求，我希望它可以在負載平衡器處停止，並在此時重定向到https。

但是硬件公司不會爲我做這件事，而是需要在服務器上的IIS中執行從http到https的重定向。因此，未加密的業務可以通過在服務器級別重定向進入內部網絡。在負載平衡器上發生這種轉移時，我會感到更加舒適。

我是否有有效的擔憂？

Answer 1

威脅模型：不管

HTTP request: 

      Attacker 
       |   Security Boundary 
       V   V 
Client -- http request --> Load Balancer 
           | 
Client <-- redirect -----------+ 

威脅從允許HTTP發生重定向方法論：

• 欺騙：客戶端可以連接到中間人欺騙不通過重定向HTTP服務器，但而是代理連接到實際的HTTPS服務器
• 篡改：客戶端可以從MITM欺騙服務器接收重定向URL，將它們引導到另一個動作（例如：客戶端接收重定向到https://yoursite.com/login.aspx?redirect=/deleteAllDocuments）
• 信息披露：披露了初始HTTP請求，POST或GET中的任何信息都可用於未加密的竊聽者。

參數進行重定向比目標服務器其他服務器：

• 防火牆可以限制爲HTTPS數據，限制了由於配置錯誤未加密數據的風險
• 配置和負債可能成爲「別人的問題「，至少從政治角度來看
• HTTP服務器中的漏洞將被隔離，無法用於攻擊HTTPS服務器或基礎應用程序

參數用於執行重定向比負載平衡器以外的東西：

• 負載平衡器不是服務器
• 負載平衡器不是服務器，因此還不如服務器，用於當已不常使用的代碼路徑，其可能是更容易出現未發現的bug或性能問題
• 配置不提供給你，但你（或你的公司）仍然可能對發生的任何錯誤的配置容易（從法律的角度）

在上面的分析中，最高的安全性與風險最低的光：

• 我會不把目標服務器上的重定向，也不是負載均衡，而是在虛擬機上只用於重定向頁面。最小的Linux或Windows應該能夠被緊緊鎖定以限制暴露。
• 我不會允許與查詢字符串或POST的數據（例如：顯示404對於任何非GET/HTTP/1.1請求）重定向
• 我稱之爲欺騙的可能性和篡改可接受的風險，或顯示一個頁面到用戶解釋，該網站必須使用HTTPS而不是使用重定向

但是，如果你可以假設滿足以下條件，將HTTP服務器共同駐留與HTTPS服務器不應該減少安全訪問。

• 在HTTP服務器的任何錯誤存在於HTTPS服務器
• HTTP服務器被正確地配置爲禁止訪問受保護資源（設置爲IIS中的單獨的站點，例如，安全站點仍然有沒有HTTP綁定）
• 沒有其他應用程序能夠創建在HTTP服務器（netsh urlacl只有IIS，例如）
• 配置被審計，以確保上述構造適當地保持（定期筆的測試中，手工配置的綜述，配置變更管理以及IDS或IPS系統）

在某些情況下，降低的複雜性甚至比單獨的服務器更容易安全。另外，如果管理員不熟悉負載平衡器的配置，他們可能更傾向於在配置中發生嚴重錯誤，而不是在他們熟悉的產品中進行相同配置。

Answer 2

我有沒有有效的擔憂？

您是否對通過HTTP進行初始連接有一個有效的關注？當然。最初的請求可以被攔截，並且在MitM攻擊中可以欺騙回應。然後，攻擊者可以阻止用戶使用HTTP（在攻擊者和服務器之間添加ssl/tls，並以明文方式中繼給受害者），或者可以與客戶端建立一個冒充者SSL會話，加密的方式給你（使用各種欺騙技術使攻擊對臨時用戶不太明顯）。

但是，如果發起這樣的攻擊，我會遠更擔心從客戶端到您的負載平衡器，而不是您的負載平衡器和IIS之間的轉移。如果您懷疑您的負載均衡器背後有惡意系統，則會遇到完全不同的問題。

Answer 3

有關從HTTP重定向到HTTPS的一些相關信息，請參閱my answer而不是security.so。