Django 專案報告：

Django 團隊今天發佈了多個版本 (Django 1.2.6 與 Django 1.3.1) 以解決報告給我們的安全性問題。
此外，本宣佈包含數個其他問題的公告，其與 Django 使用者有關，Django 本身不需要進行變動。

建議所有使用者皆立即升級 Django 並實作這些公告中的建議事項。工作階段操控 Django 的工作階段架構 django.contrib.sessions 可加以設定，以便使用多個後端中的任意個作為工作階段資料的儲存空間。Django 本身隨附的一個這種後端與 Django 的快取架構整合，可使用快取作為工作階段資料的儲存空間。

若以此方式使用記憶體型工作階段和快取進行設定，系統會使用工作階段識別碼作為金鑰，直接將 Django 工作階段儲存在快取的 root 命名空間中。

搭配使用將使用者提供的資料儲存在快取中的應用程式時，這可能會導致攻擊；如果攻擊者可使用同時為有效工作階段識別碼的金鑰來快取資料，則 Django 的工作階段架構會將該資料 (只要是類似字典的物件) 視為工作階段，因而允許攻擊者只要知道工作階段金鑰，便可將任意資料插入工作階段中。透過 URLField Django 模型系統發動的拒絕服務攻擊會包含一個欄位類型 (URLField)，其會藉由發出要求，驗證所提供的值是否為有效 URL，以及布林關鍵字引數 verify_exists 是否為 true，嘗試驗證所提供的 URL 是否也進行解析。

根據預設，Python 中的基礎通訊端程式庫不具有逾時。這可依下列三種不同方式表現為安全性問題：

- 攻擊者可提供回應緩慢的 URL。每個要求都會佔用一個伺服器處理程序一段時間；如果攻擊者可提出足夠要求，便可佔用所有可用的伺服器處理程序。

- 攻擊者可提供受其控制的 URL，且其只會無限保留開放連線。由於缺少逾時，嘗試驗證該 URL 的 Django 處理程序會同樣地無限微調。重複此程序即可輕鬆佔用所有可用的伺服器處理程序。

- 攻擊者可提供受其控制的 URL，其不只會讓連線保持開放狀態，且會傳送不需要的無止盡隨機資料流。此資料會造成 Django 處理程序 (其會將回應保留在記憶體中) 的記憶體使用量無邊界成長，因此不僅消耗伺服器處理程序，也會消耗伺服器記憶體。URLField 重新導向 負責驗證 URL 的規則運算式用於在發出驗證所提供的 URL 是否存在的檢查前，先檢查該 URL，不過如果該 URL 在要求的回應中發出重新導向，系統就不會對所產生的重新導向 URL 進行驗證，包括支援的通訊協定 (HTTP、HTTPS 和 FTP) 基本檢查在內。

這會建立一個讓攻擊者可取得資訊 (例如伺服器配置) 的小窗口；舉例而言，若重新導向至 file:// URL，攻擊者就可知道指定的檔案是否存在於伺服器本機上。

此外，雖然 Django 發出的初始要求針對 HTTP/HTTPS 使用 HEAD 方法，但是重新導向目標的要求是使用 GET 發出。這可能會對隱含信任來自本機/網路的 GET 要求之系統造成進一步問題。主機標頭快取破壞 Django 本身 (獨立於開發人員) 會在數個位置產生完整 URL (例如發出 HTTP 重新導向時)。目前 Django 使用要求中的 HTTP 主機標頭值建構 URL，其開啟了潛在的快取破壞向量：攻擊者可提交含有其所選主機標頭的要求，再接收使用該主機標頭建構 URL 的回應，而若系統快取了這個回應，便會從使用含有攻擊者所選主機的 URL 之快取中提供進一步要求。

偵測

FreeBSD : django -- 多個弱點 (d01d10c7-de2d-11e0-b215-00215c6a37bb)

high Nessus Plugin ID 56187

找不到變更記錄