Django中的SSL / HTTPS

在所有情况下，安全性总是更好，但在HTTPS后部署您的站点并不总是可行。 否则，恶意网络用户可能会嗅探身份验证凭证或客户端与服务器之间传输的任何其他信息，并且在某些情况下（主动网络攻击者）可能会更改以任一方向发送的数据。

如果您需要HTTPS提供的保护，并且已在服务器上启用它，则还需要执行一些额外的步骤：

• 如有必要，请设置SECURE_PROXY_SSL_HEADER，确保您已彻底理解了该处的警告。如果不这样做，可能会导致CSRF漏洞，如果不能正确执行，也可能很危险！

• 设置重定向，以便通过HTTP的请求重定向到HTTPS。这可以使用自定义中间件来完成。请注意SECURE_PROXY_SSL_HEADER下的警告。对于反向代理的情况，将主Web服务器配置为重定向到HTTPS可能更容易或更安全。

• 使用“安全”Cookie。如果浏览器最初通过HTTP（大多数浏览器的默认设置）进行连接，则现有cookie可能会泄露。出于这个原因，您应该将您的SESSION_COOKIE_SECURE和CSRF_COOKIE_SECURE设置设置为True。这指示浏览器仅通过HTTPS连接发送这些cookie。请注意，这将意味着会话将不能通过HTTP进行工作，并且CSRF保护将阻止任何通过HTTP接受的POST数据（如果您将所有HTTP通信重定向到HTTPS，这样会很好）。

• 使用HTTP严格传输安全性（HSTS）。 HSTS是一个HTTP标头，通知浏览器所有将来连接到特定站点的应始终使用HTTPS（请参阅下文）。结合通过HTTP将请求重定向到HTTPS，这将确保连接始终享有SSL提供的附加安全性，前提是发生了一次成功的连接。 HSTS通常在Web服务器上配置。

HTTP严格传输安全

对于只应通过HTTPS访问的网站，您可以通过设置Strict-Transport-Security标头，指示现代浏览器拒绝通过不安全连接（在给定的时间段内）连接到您的域名。这减少了您对某些SSL剥离中间人（MITM）攻击的暴露。

如果将SECURE_HSTS_SECONDS设置为非零整数值，SecurityMiddleware将为您在所有HTTPS响应中设置此标题。

启用HSTS时，首先使用小值进行测试是一个好主意，例如SECURE_HSTS_SECONDS = 3600一小时。每次Web浏览器从您的站点看到HSTS标头时，它都会拒绝在给定的时间段内与您的域进行非安全通信（使用HTTP）。

一旦您确认所有资产在您的网站上安全使用（即HSTS没有破坏任何内容），增加此值是一个好主意，这样不经常访问的人就会受到保护（31536000秒，即1年）。

此外，如果将SECURE_HSTS_INCLUDE_SUBDOMAINS设置设置为True，SecurityMiddleware会将includeSubDomains标记添加到Strict-Transport-Security标头。建议这样做（假设所有子域名都是使用HTTPS专门服务的），否则您的网站仍可能通过与子域名的不安全连接而受到攻击。

HSTS策略适用于您的整个域，而不仅仅是您设置标题的响应的URL。 因此，只有在您的整个域名仅通过HTTPS提供服务时，您才应该使用它。浏览器正确地遵守HSTS标头将拒绝允许用户绕过警告并连接到具有过期，自签名或其他无效SSL证书的网站。 如果您使用HSTS，请确保您的证书状态良好并保持这种状态

如果您部署在负载平衡器或反向代理服务器后面，并且Strict-Transport-Security头没有添加到您的响应中，可能是因为Django没有意识到它处于安全连接中; 您可能需要设置SECURE_PROXY_SSL_HEADER设置。

主机头验证

在某些情况下，Django使用客户端提供的Host头来构造URL。 尽管这些值已经过清理以防止跨站点脚本攻击，但可以将虚假主机值用于跨站点请求伪造，缓存中毒攻击以及邮件中的中毒链接。

因为即使看起来很安全的Web服务器配置也容易受到虚假主机头的影响，Django会根据django.http.HttpRequest.get_host（）方法中的ALLOWED_HOSTS设置验证主机头。

这个验证只适用于get_host（）; 如果您的代码直接从request.META访问主机头，则您将绕过此安全保护。

会话安全

与CSRF限制类似，要求部署网站以使不受信任的用户无权访问任何子域，django.contrib.sessions也具有限制。 有关详细信息，请参阅会话主题指南中的安全性部分

用户上传的内容

• 如果您的站点接受文件上传，强烈建议您将这些上载内容限制在您的Web服务器配置中，以保持合理的大小以防止拒绝服务（DOS）攻击。在Apache中，可以使用LimitRequestBody指令轻松设置。

• 如果您正在提供自己的静态文件，请确保像Apache的mod_php这样的将处理静态文件作为代码的处理程序被禁用。您不希望用户通过上传和请求特制文件来执行任意代码。

• 当媒体以不遵循安全最佳实践的方式提供时，Django的媒体上传处理会造成一些漏洞。具体来说，如果HTML文件包含有效的PNG头，然后是恶意HTML，则可以将HTML文件作为图像上传。该文件将通过Django用于ImageField图像处理（Pillow）的库的验证。当该文件随后显示给用户时，它可能会显示为HTML，具体取决于您的Web服务器的类型和配置。在框架级别没有防弹技术解决方案来安全验证所有用户上传的文件内容，但是，有一些您可以采取其他步骤来缓解这些攻击：

  1. 通过始终提供来自不同顶级或二级域的用户上传内容，可以防止一类攻击。 这样可以防止任何利用程序阻止同源策略保护，例如跨站点脚本。 例如，如果您的网站在example.com上运行，则您希望从usercontent-example.com之类的服务中提供上传的内容（MEDIA_URL设置）。 从像usercontent.example.com这样的子域中提供内容是不够的。

  2. 除此之外，应用程序可以选择为用户上传的文件定义允许的文件扩展名白名单，并将Web服务器配置为仅提供这些文件。