安全概述 · Django 中文文檔 1.8

# Django安全這份文檔是 Django 的安全功能的概述。它包括給 Django 驅動的網站一些加固建議。 ## 跨站腳本 (XSS) 防護 XSS攻擊允許用戶注入客戶端腳本到其他用戶的瀏覽器里。這通常是通過存儲在數據庫中的惡意腳本，它將檢索并顯示給其他用戶，或者通過讓用戶點擊一個鏈接，這將導致攻擊者的 JavaScript 被用戶的瀏覽器執行。然而，XSS 攻擊可以來自任何不受信任的源數據，如 Cookie 或 Web 服務，任何沒有經過充分處理就包含在網頁中的數據。使用 Django 模板保護你免受多數 XSS 攻擊。然而，重要的是要了解它提供了什么保護及其局限性。 Django 模板會[_ 編碼特殊字符 _](../ref/templates/language.html#automatic-html-escaping) ，這些字符在 HTML 中都是特別危險的。雖然這可以防止大多數惡意輸入的用戶，但它不能完全保證萬無一失。例如，它不會防護以下內容： ``` <style class=>...</style> ``` 如果 `var` 設置為 `'class1 onmouseover=javascript:func()'`, 這可能會導致在未經授權的 JavaScript 的執行，取決于瀏覽器如何呈現不完整的 HTML。（對屬性值使用引號可以修復這種情況。）同樣重要的是`is_safe`要特別小心的用在自定義模板標簽，[`safe`](../ref/templates/builtins.html#std:templatefilter-safe) 模板標簽，[`mark_safe`](../ref/utils.html#module-django.utils.safestring "django.utils.safestring: Functions and classes for working with strings that can be displayed safely without further escaping in HTML.") ，還有 autoescape 被關閉的時候。此外，如果您使用的是模板系統輸出 HTML 以外的東西，可能會有完全不同的字符和單詞需要編碼。你也應該在數據庫中存儲 HTML 的時候要非常小心，尤其是當 HTML 被檢索然后展示出來。 ## 跨站請求偽造 (CSRF) 防護 CSRF 攻擊允許惡意用戶在另一個用戶不知情或者未同意的情況下，以他的身份執行操作。 Django 對大多數類型的 CSRF 攻擊有內置的保護，在適當情況下你可以[_開啟并使用它_](../ref/csrf.html#using-csrf) 。然而，對于任何解決技術，都有它的局限性。例如，CSRF 模塊可以在全局范圍內或為特定視圖被禁用。您應該只在您知道在做什么的情況下操作。還有其他 [_限制_](../ref/csrf.html#csrf-limitations) 如果你的網站有子域名并且在你的控制之外。 [_CSRF 防護_](../ref/csrf.html#how-csrf-works) 是通過檢查每個 POST 請求的一個隨機數（nonce）來工作。這確保了惡意用戶不能簡單“回放”你網站上面表單的POST，以及讓另一個登錄的用戶無意中提交表單。惡意用戶必須知道這個隨機數，它是用戶特定的（存在cookie里）。使用 [_HTTPS_](#security-recommendation-ssl)來部署的時候，`CsrfViewMiddleware`會檢查HTTP referer協議頭是否設置為同源的URL（包括子域和端口）。因為HTTPS提供了附加的安全保護，轉發不安全的連接請求時，必須確保鏈接使用 HTTPS，并使用HSTS支持的瀏覽器。使用`csrf_exempt`裝飾器來標記視圖時，要非常小心，除非這是極其必要的。 ## SQL 注入保護 SQl注入是一種攻擊類型，惡意用戶可以在系統數據庫中執行任意SQL代碼。這可能會導致記錄刪除或者數據泄露。通過使用Django的查詢集，產生的SQL會由底層數據庫驅動正確地轉義。然而，Django也允許開發者編寫[_原始查詢_](db/sql.html#executing-raw-queries)或者執行[_自定義sql_](db/sql.html#executing-custom-sql)。這些功能應該謹慎使用，并且你應該時刻小心正確轉義任何用戶可以控制的參數。另外，你在使用[`extra()`](../ref/models/querysets.html#django.db.models.query.QuerySet.extra "django.db.models.query.QuerySet.extra")的時候應該謹慎行事。 ## 點擊劫持保護點擊劫持是一類攻擊，惡意站點在一個frame中包裹了另一個站點。這類攻擊可能導致用戶被誘導在目標站點做出一些無意識的行為。 Django在[`X-Frame-Options 中間件`](../ref/middleware.html#django.middleware.clickjacking.XFrameOptionsMiddleware "django.middleware.clickjacking.XFrameOptionsMiddleware")的表單中中含有 [_點擊劫持保護 _](../ref/clickjacking.html#clickjacking-prevention)，它在支持的瀏覽器中可以保護站點免于在frame中渲染。也可以在每個視圖中禁止這一保護，或者配置要發送的額外的協議頭。對于任何不需要將頁面包裝在三方站點的frame中，或者只需要包含它的一部分的站點，都強烈推薦啟用這一中間件。 ## SSL/HTTPS 把你的站點部署在HTTPS下總是更安全的，盡管在所有情況下不都有效。如果不這樣，惡意的網絡用戶可能會嗅探授權證書，或者其他在客戶端和服務端之間傳輸的信息，或者一些情況下 -- **活躍的**網絡攻擊者 -- 會修改在兩邊傳輸的數據。如果你想要使用HTTPS提供的保護，并且在你的服務器上開啟它，你需要遵循一些額外的步驟： * 如果必要的話，設置 [`SECURE_PROXY_SSL_HEADER`](../ref/settings.html#std:setting-SECURE_PROXY_SSL_HEADER)，確保你已經徹底了解警告。未能實現它會導致CSRF方面的缺陷，也是很危險的！ * 設置重定向，以便HTTP下的請求可以重定向到HTTPS。這可以通過自定義的中間件來實現。請注意[`SECURE_PROXY_SSL_HEADER`](../ref/settings.html#std:setting-SECURE_PROXY_SSL_HEADER)下的警告。對于反向代理的情況，配置web主服務器來重定向到HTTPS或許是最簡單也許是最安全的做法。 * 使用“安全的”cookie。如果瀏覽器的連接一開始通過HTTP，這是大多數瀏覽器的通常情況，已存在的cookie可能會被泄露。因此，你應該將[`SESSION_COOKIE_SECURE`](../ref/settings.html#std:setting-SESSION_COOKIE_SECURE) 和[`CSRF_COOKIE_SECURE`](../ref/settings.html#std:setting-CSRF_COOKIE_SECURE)設置為`True`。這會使瀏覽器只在HTTPS連接中發送這些cookie。要注意這意味著會話在HTTP下不能工作，并且CSRF保護功能會在HTTP下阻止接受任何POST數據（如果你把所有HTTP請求都重定向到HTTPS之后就沒問題了）。 * 使用 HTTP 強制安全傳輸 (HSTS) HSTS 是一個HTTP協議頭，它通知瀏覽器，到特定站點的所有鏈接都一直使用HTTPS。通過和重定向HTTP請求到HTTPS一起使用，確保連接總是享有附加的SSL安全保障，由一個已存在的成功的連接提供。HSTS通常在web服務器上面配置。 ## Host 協議頭驗證在某些情況下，Django使用客戶端提供的`Host` 協議頭來構造URL。雖然這些值可以被審查，來防止跨站腳本攻擊（XSS），但是一個假的`Host`值可以用于跨站請求偽造（CSRF），有害的緩存攻擊，以及email中的有害鏈接。 Because even seemingly-secure web server configurations are susceptible to fake `Host` headers, Django validates `Host` headers against the [`ALLOWED_HOSTS`](../ref/settings.html#std:setting-ALLOWED_HOSTS) setting in the [`django.http.HttpRequest.get_host()`](../ref/request-response.html#django.http.HttpRequest.get_host "django.http.HttpRequest.get_host") method. 驗證只通過[`get_host()`](../ref/request-response.html#django.http.HttpRequest.get_host "django.http.HttpRequest.get_host")來應用；如果你的代碼從`request.META`中直接訪問`Host`協議頭，就會繞開這一安全防護。詳見完整的[`ALLOWED_HOSTS`](../ref/settings.html#std:setting-ALLOWED_HOSTS)文檔。 Warning Previous versions of this document recommended configuring your web server to ensure it validates incoming HTTP `Host` headers. While this is still recommended, in many common web servers a configuration that seems to validate the `Host` header may not in fact do so. For instance, even if Apache is configured such that your Django site is served from a non-default virtual host with the `ServerName` set, it is still possible for an HTTP request to match this virtual host and supply a fake `Host` header. Thus, Django now requires that you set [`ALLOWED_HOSTS`](../ref/settings.html#std:setting-ALLOWED_HOSTS) explicitly rather than relying on web server configuration. 另外，就像1.3.1，如果你的配置需要它的話，Django 需要你顯式開啟對`X-Forwarded-Host` 協議頭的支持(通過 [`USE_X_FORWARDED_HOST`](../ref/settings.html#std:setting-USE_X_FORWARDED_HOST) 這只)。 ## Session 會話安全類似于部署在站點上的[_CSRF 限制_](../ref/csrf.html#csrf-limitations) 使不受信任的用戶不能訪問任何子域，[`django.contrib.sessions`](http/sessions.html#module-django.contrib.sessions "django.contrib.sessions: Provides session management for Django projects.")也有一些限制。詳見[_安全中會話的話題指南_](http/sessions.html#topics-session-security)。 ## 用戶上傳的內容注意考慮[_在云服務器或CDN上面部署靜態文件_](../howto/static-files/deployment.html#staticfiles-from-cdn)來避免一些此類問題。 * 如果你的站點接受上傳文件，強烈推薦你在web服務器配置中，將這些上傳限制為合理的大小，來避免拒絕服務（DOS）攻擊。在Apache中，這可以簡單地使用[LimitRequestBody](http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestbody)指令。 * 如果你自己處理靜態文件，確保像Apache的`mod_php`的處理器已關閉，它會將靜態文件執行為代碼。你并不希望用戶能夠通過上傳和請求一個精心構造的文件來執行任意代碼。 * Django’s media upload handling poses some vulnerabilities when that media is served in ways that do not follow security best practices. Specifically, an HTML file can be uploaded as an image if that file contains a valid PNG header followed by malicious HTML. This file will pass verification of the library that Django uses for [`ImageField`](../ref/models/fields.html#django.db.models.ImageField "django.db.models.ImageField") image processing (Pillow). When this file is subsequently displayed to a user, it may be displayed as HTML depending on the type and configuration of your web server. No bulletproof technical solution exists at the framework level to safely validate all user uploaded file content, however, there are some other steps you can take to mitigate these attacks: * One class of attacks can be prevented by always serving user uploaded content from a distinct top-level or second-level domain. This prevents any exploit blocked by [same-origin policy](http://en.wikipedia.org/wiki/Same-origin_policy) protections such as cross site scripting. For example, if your site runs on `example.com`, you would want to serve uploaded content (the [`MEDIA_URL`](../ref/settings.html#std:setting-MEDIA_URL) setting) from something like `usercontent-example.com`. It’s _not_ sufficient to serve content from a subdomain like `usercontent.example.com`. 2. 除此之外，應用可以選擇為用戶上傳的文件定義一個允許的文件擴展名的白名單，并且配置web服務器直處理這些文件。 ## 額外的安全話題雖然Django提供了開箱即用的，良好的安全保護，但是合理地部署你的應用，以及利用web服務器、操作系統和其他組件的安全保護仍然很重要。 * 確保你的Python代碼在web服務器的根目錄外。這會確保你的Python代碼不會意外被解析為純文本（或者意外被執行）。 * 小心處理任何[_用戶上傳的文件_](../ref/models/fields.html#file-upload-security)。 * Django并不限制驗證用戶的請求。要保護對驗證系統的暴力破解攻擊，你可以考慮部署一個DJango的插件或者web服務器模塊來限制這些請求。 * 秘密保存[`SECRET_KEY`](../ref/settings.html#std:setting-SECRET_KEY)。 * 使用防火墻來限制緩存系統和數據庫的訪問是個好主意。 > 譯者：[Django 文檔協作翻譯小組](http://python.usyiyi.cn/django/index.html)，原文：[Security overview](https://docs.djangoproject.com/en/1.8/topics/security/)。 > > 本文以 [CC BY-NC-SA 3.0](http://creativecommons.org/licenses/by-nc-sa/3.0/cn/) 協議發布，轉載請保留作者署名和文章出處。 > > [Django 文檔協作翻譯小組](http://python.usyiyi.cn/django/index.html)人手緊缺，有興趣的朋友可以加入我們，完全公益性質。交流群：467338606。