基于Django的安全性学习（下）

SSL/HTTPS

通过 HTTPS 部署网页是保障安全的最佳办法。没有它，恶意用户就可以在客户端和服务器之间嗅探验证资格或其他信息，在某些情况下，比如：主动网络攻击者，会修改发送中的数据。
设置 SECURE_PROXY_SSL_HEADER，否则，将会导致 CSRF 漏洞，如果操作不正确，也是非常危险的。
设置 SECURE_SSL_REDIRECT 为 True，这样 HTTP 的请求就会被重定向到 HTTPS。
SECURE_PROXY_SSL_HEADER 下的警告。对于反向代理，设置主服务器去执行重定向到 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 要么在 Web 服务器上配置，要么通过 SECURE_HSTS_SECONDS， SECURE_HSTS_INCLUDE_SUBDOMAINS，以及 SECURE_HSTS_PRELOAD 来进行配置

在某些情况下，Django 使用客户端提供的 Host 头部来构造 URLs。这些值虽被清理以阻止跨站脚本攻击，但伪造 Host 值还是可以用于跨站请求伪造，缓存毒化攻击，以及电子邮件中的有毒链接。
因为即使看起来安全的服务器配置也容易受到假的 Host 头部信息的影响，Django 依靠定义在 django.http.HttpRequest.get_host() 方法中的 ALLOWED_HOSTS 来验证 Host 头部。
这些验证仅通过 get_host() 来实现；如果代码直接从 request.META 得到 Host 头部，就绕过了这种安全保护机制。

浏览器使用 Referer 头部来把关于用户是如何到达那里的信息发送到网站。通过设置 Referrer 策略，限制在哪些情况下设置 Referer 头部，可以保护您用户的隐私。

类似于 CSRF 限制要求一个被部署的网页应让不受信任的用户不能访问任何子域，django.contrib.sessions 也有限制。

可以从云服务或 CDN 提供静态文件服务来避免此类问题。
如果网站接受文件上传，可以在服务器配置中将这些上传限制在合理大小范围中，以此来防御拒绝服务（DOS）攻击。在 Apache 中，使用 LimitRequestBody 指令可以很容易地实现这个设置。
如果为自己的静态文件提供服务，确保像 Apache 的 mod_php 这种能把静态文件当作代码来执行的处理程序已经关闭。
如果媒体文件没有遵循安全性最佳惯例，Django 的媒体上传处理会产生一些漏洞。特别的，如果一个 HTML 文件包含合法的 PNG 格式头部并附加一些恶意的 HTML，它是可以作为一个图片文件上传的。该文件将会通过 Django 用于 ImageField 图片处理（Pillow）库的验证。当此文件随后被展示给用户时，它可以被显示为 HTML
在框架级别上没有防护技术方案可以安全地验证所有用户上传的文件内容，但是可以采取其他步骤来减轻这些攻击：
通过一直为来自不同顶级域名或二级域名的用户提供上传内容可以防御一类的攻击。这可以防止被 same-origin policy 保护机制阻止的任何攻击，比如跨站脚本攻击。
除此之外，应用可以选择定义一个列表来限制允许用户上传的文件的扩展名，并将 Web 服务器配置为仅为此类文件服务。