Django 的安全性¶
此文档是对 Django 安全特性的概述。包含保障那些用 Django 建立的网站的安全性建议。
Always sanitize user input¶
The golden rule of web application security is to never trust user-controlled data. Hence, all user input should be sanitized before being used in your application. See the forms documentation for details on validating user inputs in Django.
防御跨站脚本攻击（XSS）¶
XSS 攻击允许用户将客户端脚本注入到其他用户的浏览器中。这通常是通过将恶意脚本存储在数据库中，在那里它将被检索并显示给其他用户，或者通过让用户点击一个链接，使攻击者的 JavaScript 被用户的浏览器执行来实现。然而，XSS 攻击可以来自任何不受信任的数据源，如 cookie 或网络服务，只要数据在被纳入页面之前没有被充分净化。
Django 模板可以保护您免受大多数 XSS 攻击。但是了解它提供了怎样的保护，以及有什么限制是很重要的。
对于 HTML 来说，Django 模板中的 转义特殊字符 是尤其危险的。虽然它保护用户免受大多数恶意输入的攻击，但并非万无一失。比如，出现下面这种情况就会保护失效：
<style class={{ var }}>...</style>
如果 var 被设置为 'class1 onmouseover=javascript:func()' ，将导致未经授权的 JavaScript 脚本执行，这取决于浏览器如何渲染有缺陷的HTML。（引用属性值可以解决这个问题）
与此不相上下的还有在使用带有自定义模板标签的 is_safe ，safe 模板标签，mark_safe，以及关闭自动转义时要特别小心。
此外，如果使用模板系统输出了除 HTML 之外的内容，可能会有完全独立的字符和单词需要转义。
您在将 HTML 储存到数据库中时也要非常小心，特别是在检索和显示 HTML 的时候。
防御跨站点请求伪造（CSRF）¶
发起 CSRF 攻击的人可以使用其他用户的证书执行操作，且是在其不知情或不同意的情况下。
Django 内置了保护措施来防御大多数 CSRF 攻击，您需要在合适的地方 授权并使用它 。但和多数缓解性技术一样，它是有局限性的。比如可以全局禁用 CSRF 模块或者特定的视图。请三思而后行。如果您的网页还有脱离您控制的子域，还将会有其他 限制 。
CSRF 保护机制 通过检查每一个 POST 请求中的密文来实现。这保证恶意用户不能“复现”一个表单并用 POST 提交到你的网页，并让一个已登录用户无意中提交该表单。恶意用户必须知道特定于用户的密文（使用 cookie）。
在部署 HTTPS 时，CsrfViewMiddleware 会检查 HTTP 报文的 referer 首部是否设置为同源的 URL（包括子域和端口）。因为 HTTPS 提供了额外的安全性，所有通过转发不安全连接请求并在支持的浏览器中使用 HSTS 来确保连接在可用的地方使用了 HTTPS ，这一点是很重要的。
除非绝对需要，否则对视图进行标记 csrf_exempt 装饰器时要极其慎重。
防御 SQL 注入¶
SQL 注入能让恶意用户能在数据库中执行任意 SQL 代码。这将导致记录被删除或泄露。
Django 的 querysets 在被参数化查询构建出来时就被保护而免于 SQL 注入。查询的 SQL 代码与查询的参数是分开定义的。参数可能来自用户从而不安全，因此它们由底层数据库引擎进行转义。
Django 也为开发者提供了书写 原始查询 或执行 自定义 sql 的权力。应当尽可能少地使用这些方法，并且您应该小心并准确地转义一切用户可控的参数。另外，在使用 extra() 和 RawSQL 时应当小心谨慎。
防御访问劫持¶
访问劫持能让恶意网页覆盖另一个网页。可能会有毫不知情的用户被骗入目标网页并执行意料之外的操作。
Django 包含 访问劫持保护 ，以 X-Frame-Options middleware 的形式在支持它的浏览器中阻止一个网页被渲染在 frame 的内部。可在每个视图的基础上禁用保护，也可配置发送的确切头部值。
对于任何不会被第三方网站嵌入 frame 的网页，或者只允许使用一小部分的网页来说，强烈建议使用中间件。
SSL/HTTPS¶
通过 HTTPS 部署您的网页是保障安全的最佳办法。没有它，恶意用户就可以在客户端和服务器之间嗅探验证资格或其他信息，在某些情况下 -- 比如 主动 网络攻击者 -- 会修改发送中的数据。
如果您想得到 HTTPS 的保护，且已经在您的服务器上启用了，下面还有一些额外的步骤需要执行：
如有必要，设置
SECURE_PROXY_SSL_HEADER，确保您已经彻底的了解了它的警告提示。如果不这么做，将会导致 CSRF 漏洞，如果操作不正确，也是非常危险的。设置
SECURE_SSL_REDIRECT为True，这样 HTTP 的请求就会被重定向到 HTTPS。请注意
SECURE_PROXY_SSL_HEADER下的注意事项。对于反向代理的情况，配置主 Web 服务器来做重定向到 HTTPS 可能更容易或更安全。使用 'secure' cookies。
如果浏览器使用默认的 HTTP 来实现初始连接，可能会导致已有的 cookies 泄露。因此，您应当将
CSRF_COOKIE_SECURE和CSRF_COOKIE_SECURE设置为True。这样浏览器就会仅用 HTTPS 连接来发送 cookies。注意，这会使得 sessions 不能再通过 HTTP 工作，且 CSRF 防御机制将会阻止任何通过 HTTP 接收到的 POST 数据（当然把所有 HTTP 都弄成 HTTPS 是最好的）。使用 HTTP 严格传输安全 （HSTS）
HSTS 是一个 HTTP 标头，它通知浏览器，所有未来连接到一个特定的网站应该始终使用 HTTPS。结合重定向 HTTP 请求到 HTTPS，这将确保连接总是享受 SSL 的额外安全，只要有一个成功的连接发生。HSTS 可以通过
SECURE_HSTS_SECONDS、SECURE_HSTS_INCLUDE_SUBDOMAINS和SECURE_HSTS_PRELOAD来配置，或者在网络服务器上配置。
Host 头部验证¶
在某些情况下，Django 使用客户端提供的 Host 头部来构造 URLs。这些值虽被清理以阻止跨站脚本攻击，但伪造 Host 值还是可以用于跨站请求伪造，缓存毒化攻击，以及电子邮件中的有毒链接。
因为即使看起来安全的服务器配置也容易受到假的 Host 头部信息的影响，Django 依靠定义在 django.http.HttpRequest.get_host() 方法中的 ALLOWED_HOSTS 来验证 Host 头部。
这些验证仅通过 get_host() 来实现；如果您的代码直接从 request.META 得到 Host 头部，您就绕过了这种安全保护机制。
更多细节请参照完整的 ALLOWED_HOSTS 文档。
Warning
本文档的较早版本建议配置你的网络服务器，以确保它验证传入的 HTTP Host 头。虽然我们现在还是这样建议，但在许多常见 Web 服务器中，看似验证了 Host 头的配置，实际上却没有验证。例如，即使 Apache 的配置是让你的 Django 网站从一个非默认的虚拟主机上运行，并设置了 "ServerName"，HTTP 请求仍然有可能匹配这个虚拟主机，并提供一个假的 "Host " 头。因此，Django 现在要求你显式地设置 ALLOWED_HOSTS，而不是依赖 Web 服务器的配置。
另外，如果您的配置需要，Django 要求您明确启用对 X-Forwarded-Host 标头的支持（通过 USE_X_FORWARDED_HOST 配置）。
Referrer 策略¶
浏览器使用 Referer 头部来把关于用户是如何到达那里的信息发送到网站。通过设置 Referrer 策略，限制在哪些情况下设置 Referer 头部，可以保护您用户的隐私。请看 安全中间件参考中的 referrer 策略部分 了解更多细节。
跨源弹出式窗口策略¶
跨源弹出式窗口策略（COOP）头允许浏览器将一个顶级窗口与其他文档隔离，把它们放在不同的上下文组中，使它们不能直接与顶级窗口交互。如果一个受 COOP 保护的文档打开了一个跨源弹出窗口，该弹出窗口的 window.opener 属性将为 null。COOP 可以防止跨源攻击。详情请看 安全中间件参考资料中的跨源弹出式窗口策略部分。
会话安全¶
类似于 CSRF 限制 要求一个被部署的网页应让不受信任的用户不能访问任何子域，django.contrib.sessions 也有限制。参照 会话主题指南中关于安全的部分 获取更多细节。
用户上传内容¶
Note
考虑 从云服务或 CDN 提供静态文件服务 来避免此类问题。
如果你的网站接受文件上传，强烈建议你在你的网络服务器配置中把这些上传文件限制在一个合理的大小，以防止拒绝服务（DOS）攻击。在 Apache 中，可以使用 LimitRequestBody 指令轻松设置。
如果您为自己的静态文件提供服务，确保像 Apache 的
mod_php这种能把静态文件当作代码来执行的处理程序已经关闭。您绝不会希望用户能够通过上传并请求特制文件来执行任意的代码。如果媒体文件没有遵循安全性最佳惯例，Django 的媒体上传处理会产生一些漏洞。特别的，如果一个 HTML 文件包含合法的 PNG 格式头部并附加一些恶意的 HTML，它是可以作为一个图片文件上传的。该文件将会通过 Django 用于
ImageField图片处理（Pillow）库的验证。当此文件随后被展示给用户时，它可以被显示为 HTML，这取决于您的服务器类型于配置。在框架级别上没有防护技术方案可以安全地验证所有用户上传的文件内容，但是您可以采取其他步骤来减轻这些攻击：
通过一直为来自不同顶级域名或二级域名的用户提供上传内容可以防御一类的攻击。这可以防止被 same-origin policy 保护机制阻止的任何攻击，比如跨站脚本攻击。例如您的网站是
example.com，您应当通过形如usercontent-example.com的方式来提供上传内容服务（配置MEDIA_URL）。仅仅从像usercontent.example.com这样的子域提供内容是*不够*的。除此之外，应用可以选择定义一个列表来限制允许用户上传的文件的扩展名，并将 Web 服务器配置为仅为此类文件服务。
其他安全性相关主题¶
虽然 Django 开箱即提供了良好的安全保护，但正确部署你的应用程序并利用网络服务器、操作系统和其他组件的安全保护仍然很重要。
确保你的 Python 代码是在网络服务器的根目录之外。这将确保你的 Python 代码不会被意外地作为纯文本提供（或意外地执行）。
小心一切 用户上传的文件。
Django 不会对认证用户的请求进行节流。为了防止针对认证系统的暴力攻击，你可以考虑部署一个 Django 插件或网络服务器模块来节制这些请求。
保持您的
SECRET_KEY，以及如果正在使用的话，SECRET_KEY_FALLBACKS保持保密。用防火墙限制缓存系统和数据库的可访问性是个好主意。
看一下开源 Web 应用安全计划（OWASP） Top 10 list ，它指定了网络应用程序中一些常见的漏洞。尽管 Django 拥有解决某些问题的工具，但在项目设计中必须考虑其他问题。
Mozilla 讨论了很多与 web security 相关的主题。他们的网页还包括适用于任何系统的安全原则。
