摘要

這些安全更新修復了四個問題：一個潛在的網路釣魚媒介、一個阻斷服務媒介、一個資訊洩漏問題，以及一系列 XML 漏洞。

以下是每個問題及其解決方案的簡要摘要

• 問題：主機標頭中毒：攻擊者可能導致 Django 生成並顯示連結到任意網域的 URL。這可能被用作網路釣魚攻擊的一部分。這些版本透過引入一個新的設定 ALLOWED_HOSTS 來修復此問題，該設定指定您的網站已知會回應的網域白名單。

  重要：預設情況下，Django 1.3.6 和 1.4.4 將 ALLOWED_HOSTS 設定為允許所有主機。這表示若要實際修復安全漏洞，您應在升級後立即自行定義此設定。

• 問題：表單集阻斷服務：攻擊者可以濫用 Django 對表單集中表單數量的追蹤，以導致阻斷服務攻擊。此問題已透過新增預設最大表單數量 1,000 來修復。如果您願意，您仍然可以手動指定較大的 max_num，但 1,000 對任何人來說都應該足夠了。

• 問題：XML 攻擊：Django 的序列化框架容易受到透過 XML 實體擴展和外部參考的攻擊；此問題現已修復。但是，如果您在應用程式的其他部分解析任意 XML，我們建議您研究 defusedxml Python 套件，它們可以在任何您解析 XML 的地方（而不僅僅是透過 Django 的序列化框架）修復此問題。

• 問題：透過管理介面歷史記錄記錄的資料洩漏：Django 的管理介面可能會透過其歷史記錄記錄洩漏本應隱藏的資訊。此問題已修復。

如需更多詳細資訊，請繼續閱讀。

問題：主機標頭中毒

先前發布的幾個 Django 安全更新都試圖解決 HTTP Host 標頭的持續性問題。 Django 包含程式碼 -- 以及 Django 本身隨附的一些功能會使用該程式碼 -- 用於根據傳入的 HTTP 請求建構完整合格的 URL。根據設定，這會使用 Host 標頭，因此，可以導致 Django 應用程式回應任意 Host 標頭的攻擊者，可能會導致 Django 在任意網域上產生 URL 並顯示給最終使用者。

先前此問題的迭代 (請參閱 CVE-2011-4139 和 CVE-2012-4520) 側重於加強 Django 對 Host 標頭的解析，以消除攻擊者使用諸如在其提交的 Host 標頭中使用使用者名稱/密碼對之類技術的各種方法來利用此問題。

但是，最終，Django 無法單獨確保攻擊者無法提交並導致 Django 接受任意 Host 標頭。在已部署的 Django 執行個體中正確保護此功能，還需要設定 Web 伺服器，並且設定和可實現的安全等級會隨著使用的伺服器而變化。

有鑑於此，django.http.HttpRequest 的 get_host() 方法現在將根據新的設定 ALLOWED_HOSTS 驗證 Host 標頭。此設定是與標頭可接受值相對應的字串列表 (預設為空列表)，並支援一些萬用字元。

不使用 get_host() 的程式碼，或無需求助 HTTP 標頭即可確定目前主機名稱的 Django 設定 (即啟用 Django 的網站框架時) 不會受到此變更的影響。

由於這是對先前問題的強化/加強，因此沒有新的 CVE 編號。

問題：XML 攻擊

Django 的序列化框架包含對序列化為 XML 和從 XML 還原序列化的支援。 Django 的 XML 還原序列化容易受到實體擴展和外部實體/DTD 攻擊。

為了補救此問題，Django 的 XML 還原序列化程式不再允許 DTD、執行實體擴展或提取外部實體/DTD。請注意，這僅保護 Django 的 XML 序列化框架；如果您的應用程式解析 XML，我們建議您研究 defusedxml Python 套件，它們可以針對 Python 本身修復此問題。

由於此問題也會影響 Python 的 XML 程式庫，因此它涵蓋在 Python 的 CVE-2013-1664 和 CVE-2013-1665 中。

問題：透過管理介面歷史記錄記錄的資料洩漏

Django 的捆綁管理介面會保留所執行動作的記錄，保留透過管理介面公開的任何物件的歷史記錄。此歷史記錄檢視不會執行任何超出確認使用者可以存取管理介面的權限檢查；因此，任何具有管理員權限的使用者都可以檢視管理介面中可存取之任何物件的歷史記錄，並查看對物件所做之每次變更的摘要。

為了補救此問題，物件的管理介面歷史記錄檢視現在將執行與同一物件的其他管理檢視相同的權限檢查。

此問題為 CVE-2013-0305。

問題：表單集阻斷服務

Django 的表單程式庫包含用於產生表單集的工具 -- 一個表單的多個執行個體，同時提交 (例如，用於大量編輯/更新類似的物件)。 表單集允許一個參數 max_num，指定可以顯示的最大個別表單數量。然後，表單集中的隱藏輸入會指定要提交的表單數量。

Django 會接受提交的隱藏值，並嘗試實例化許多表單物件。足夠大的值會導致極大的記憶體消耗；超過 sys.maxint 的值在此情況下會導致 HTTP 500 回應 (由於來自過大值的未捕獲 OverflowError)。在前一種情況下，結果是有效的阻斷服務攻擊。在後一種情況下，攻擊者可能會導致任意伺服器錯誤。

為了解決此問題，Django 現在將為表單的最大數量提供 (適當大的) 預設值，當未提供 max_num 時將使用該值。應用程式開發人員仍然可以手動指定 max_num 以滿足其應用程式的需求，但在沒有此情況下，預設值 -- 1000 -- 將確保攻擊者不會導致溢位錯誤或過度記憶體消耗。

此問題為 CVE-2013-0306。

受影響的版本

上述問題會影響以下版本的 Django

• Django 主要開發分支
• Django 1.5 發行分支 (即將成為 Django 1.5)
• Django 1.4 發行分支
• Django 1.3 發行分支

解決方案

已將修補程式應用於 Django 的主要開發分支以及 1.5、1.4 和 1.3 發行分支，這些修補程式解決了上述問題。這些修補程式可以直接從以下變更集中取得。

在開發主要分支上

• 主要主機標頭
• 主要 XML 擴展
• 主要管理介面洩漏
• 主要表單集驗證

在 Django 1.5 發行分支上

• 1.5 主機標頭
• 1.5 XML 擴展
• 1.5 管理介面洩漏
• 1.5 表單集驗證

在 Django 1.4 發行分支上

• 1.4 主機標頭
• 1.4 XML 擴展
• 1.4 管理介面洩漏
• 1.4 表單集驗證

在 Django 1.3 發行分支上

• 1.3 主機標頭
• 1.3 XML 擴展
• 1.3 管理介面洩漏
• 1.3 表單集驗證

已發布以下新版本

• Django 1.5 發布候選版本 2 (下載 1.5 RC 2 | 1.5 RC 2 總和檢查碼)
• Django 1.4.4 (下載 1.4.4 | 1.4.4 總和檢查碼)
• Django 1.3.6 (下載 1.3.6 | 1.3.6 總和檢查碼)

鳴謝

再次追蹤 Host 標頭問題來自 James Kettle。 XML 漏洞是由 Rails 的 Michael Koziarski 向我們回報的。修補程式的要點來自 Christian Heimes。管理介面資訊洩漏問題是由 Orange Tsai 回報的。表單集驗證問題是由 Mozilla 回報的。

關於安全回報的一般說明

一如既往，我們要求潛在的安全問題透過私人電子郵件回報給 security@djangoproject.com，而不是透過 Django 的 Trac 執行個體或 django-developers 清單回報。請參閱我們的安全政策以取得更多資訊。