Django 安全（未完成）

原文：https://docs.djangoproject.com/en/1.6/topics/security

这篇文章几乎囊括了 Django 站点安全性的方方面面。

Security in Django

This document is an overview of Django’s security features. It includes advice on securing a Django-powered site.

★ 此文概要性的介绍了 Django 安全 

Cross site scripting (XSS) protection  ★ 脚本跨站点攻击（注入攻击）

 http://www.yihaomen.com/article/python/427.htm  （例子，django 防止xss注入的方法）

XSS attacks allow a user to inject client side scripts into the browsers of other users. This is usually achieved by storing the malicious scripts in the database where it will be retrieved and displayed to other users, or by getting users to click a link which will cause the attacker’s JavaScript to be executed by the user’s browser. However, XSS attacks can originate from any untrusted source of data, such as cookies or Web services, whenever the data is not sufficiently sanitized before including in a page.

★ XSS 攻击：迫使或欺骗其他用户执行攻击者在客户端注入的脚本。通常，在db里存放恶意脚本，这些脚本会被检索或展示给用户，欺骗用户点击带有恶意 Javascript 的网页。当没有对数据进行安全过滤时，任何不可靠不可信的数据都可能引起 XSS 攻击，例如 cookies 或 web服务。

Using Django templates protects you against the majority of XSS attacks. However, it is important to understand what protections it provides and its limitations.

★ 使用 Django 模板能防止大部分的 XSS 攻击。然而，很有必要明白 Django 提供了哪些防护功能，和它本身的一些限制。

Django templates escape specific characters which are particularly dangerous to HTML. While this protects users from most malicious input, it is not entirely foolproof. For example, it will not protect the following:

★ Django 会过滤那些对HTML怀有恶意的指定的字符串。这防止用户注入恶意的代码，但这也不是万无一失的方法。例如它防止不了下面的代码。

<style class={{ var }}>...</style>

If var is set to 'class1 onmouseover=javascript:func()', this can result in unauthorized JavaScript execution, depending on how the browser renders imperfect HTML.

★ var 被设置成 'class1 onmouseover=javascript:func()' ，这会导致不安全的 JavaScript 脚本的执行，这取决于浏览器如何渲染有缺陷的 HTML 。

It is also important to be particularly careful when using is_safe with custom template tags, the safe template tag, mark_safe, and when autoescape is turned off.

★ 当在定制的模板标签里使用 is_sage, safe, mark_safe 时尤其要注意，因为这时自动转换是被关闭的 

In addition, if you are using the template system to output something other than HTML, there may be entirely separate characters and words which require escaping.

★ 另外，使用模板系统输出非HTML的东东时，或许会有被Django过滤的字符串

You should also be very careful when storing HTML in the database, especially when that HTML is retrieved and displayed.

★ 当把 HTML 存放到数据库时要小心，尤其是 HTML 要被最终展示给用户时。

Cross site request forgery (CSRF) protection  ★ 跨站伪造 

http://www.cnblogs.com/lins05/archive/2012/12/02/2797996.html  （例子，Django 的 CSRF 保护机制）

http://blog.sina.com.cn/s/blog_3fe961ae010164i5.html （例子，带图解）

CSRF attacks allow a malicious user to execute actions using the credentials of another user without that user’s knowledge or consent.

★ CSRF 攻击：恶意的使用其他用户的身份

Django has built-in protection against most types of CSRF attacks, providing you have enabled and used it where appropriate. However, as with any mitigation technique, there are limitations. For example, it is possible to disable the CSRF module globally or for particular views. You should only do this if you know what you are doing. There are other limitations if your site has subdomains that are outside of your control.

★ Django 自带内建的防止 CSRF 攻击的功能，需要使用时引用csrf标签即可。然而，和许多傻瓜式的技术一样，这个功能也存在诸多限制。比如，在全站还是个别页面范围里，是否使用防CSRF攻击的功能是可选择的，你应该根据你所做所为选择是否使用此功能。如果你的站点有子域名，也有其它的一些限制。

CSRF protection works by checking for a nonce in each POST request. This ensures that a malicious user cannot simply “replay” a form POST to your Web site and have another logged in user unwittingly submit that form. The malicious user would have to know the nonce, which is user specific (using a cookie).

★ Django CSRF 检查POST请求里的临时变量，确保了恶意的用户不能重复提交 POST 表单，使其他登陆用户无意地提交这个表单。恶意用户必须知道这个特别的临时变量（存放在 cookie 里）

When deployed with HTTPS, CsrfViewMiddleware will check that the HTTP referrer header is set to a URL on the same origin (including subdomain and port). Because HTTPS provides additional security, it is imperative to ensure connections use HTTPS where it is available by forwarding insecure connection requests and using HSTS for supported browsers.

★ 当用 HTTPS 部署后，CsrfViewMiddleware 会检查 HTTP 头是否来自同一个用户（包括子域名和端口）。 由于 HTTPS 提供了额外的安全保障，转发不安全的连接请求，时，必须确保链接使用 HTTPS，并使用HSTS支持的浏览器。

Be very careful with marking views with the csrf_exempt decorator unless it is absolutely necessary.

★ 在绝对必须的时候，才使用csrf_exempt 装饰器。

SQL injection protection  ★ SQL注入防护

SQL injection is a type of attack where a malicious user is able to execute arbitrary SQL code on a database. This can result in records being deleted or data leakage.

★ SQL 注入：恶意用户在数据库上执行SQL代码，这会导致服务器数据被恶意删除或泄露 给攻击者者 

By using Django’s querysets, the resulting SQL will be properly escaped by the underlying database driver. However, Django also gives developers power to write raw queries or execute custom sql. These capabilities should be used sparingly and you should always be careful to properly escape any parameters that the user can control. In addition, you should exercise caution when using extra().

★ 使用 Django 的 querysets，确保数据库检索的安全性。然而，Django 也提供了 原始SQL文 检索，这些功能应当尽量少用，必须总是确保用户能够输入的部分是安全的。另外，使用 extra() 方法时要小心。 

Clickjacking protection

Clickjacking is a type of attack where a malicious site wraps another site in a frame. This attack can result in an unsuspecting user being tricked into performing unintended actions on the target site.

★点击劫持（clickjacking）是一种在网页中将恶意代码等隐藏在看似无害的内容（如按钮）之下，并诱使用户点击的手段。举例来说，如用户收到一封包含一段视频的电子邮件，但其中的“播放”按钮并不会真正播放视频，而是链入一购物网站。这样当用户试图“播放视频”时，实际是被诱骗而进入了一个购物网站。（来自维基百科）

Django contains clickjacking protection in the form of the X-Frame-Options middleware which in a supporting browser can prevent a site from being rendered inside a frame. It is possible to disable the protection on a per view basis or to configure the exact header value sent.

★ Django 通过X-Frame-Options middleware 的方式防止点击劫持，支持此方式的浏览器能够防止站点被恶意地嵌套。可以在页面上使保护失效，或可以配置发送的确切头部（header）

The middleware is strongly recommended for any site that does not need to have its pages wrapped in a frame by third party sites, or only needs to allow that for a small section of the site.

★ 强烈推荐所有不需要被其它“包装”的网页都使用中间件

SSL/HTTPS

It is always better for security, though not always practical in all cases, to deploy your site behind HTTPS. Without this, it is possible for malicious network users to sniff authentication credentials or any other information transferred between client and server, and in some cases – active network attackers – to alter data that is sent in either direction.

If you want the protection that HTTPS provides, and have enabled it on your server, there are some additional steps you may need:

• If necessary, set SECURE_PROXY_SSL_HEADER, ensuring that you have understood the warnings there thoroughly. Failure to do this can result in CSRF vulnerabilities, and failure to do it correctly can also be dangerous!

• Set up redirection so that requests over HTTP are redirected to HTTPS.

  This could be done using a custom middleware. Please note the caveats under SECURE_PROXY_SSL_HEADER. For the case of a reverse proxy, it may be easier or more secure to configure the main Web server to do the redirect to HTTPS.

• Use ‘secure’ cookies.

  If a browser connects initially via HTTP, which is the default for most browsers, it is possible for existing cookies to be leaked. For this reason, you should set your SESSION_COOKIE_SECURE and CSRF_COOKIE_SECURE settings to True. This instructs the browser to only send these cookies over HTTPS connections. Note that this will mean that sessions will not work over HTTP, and the CSRF protection will prevent any POST data being accepted over HTTP (which will be fine if you are redirecting all HTTP traffic to HTTPS).

• Use HTTP Strict Transport Security (HSTS)

  HSTS is an HTTP header that informs a browser that all future connections to a particular site should always use HTTPS. Combined with redirecting requests over HTTP to HTTPS, this will ensure that connections always enjoy the added security of SSL provided one successful connection has occurred. HSTS is usually configured on the web server.

Host header validation

Django uses the Host header provided by the client to construct URLs in certain cases. While these values are sanitized to prevent Cross Site Scripting attacks, a fake Host value can be used for Cross-Site Request Forgery, cache poisoning attacks, and poisoning links in emails.

Because even seemingly-secure web server configurations are susceptible to fake Host headers, Django validates Host headers against the ALLOWED_HOSTS setting in the django.http.HttpRequest.get_host() method.

This validation only applies via get_host(); if your code accesses the Host header directly from request.META you are bypassing this security protection.

For more details see the full ALLOWED_HOSTS documentation.

Warning

Previous versions of this document recommended configuring your web server to ensure it validates incoming HTTPHost 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 explicitly rather than relying on web server configuration.

Additionally, as of 1.3.1, Django requires you to explicitly enable support for the X-Forwarded-Host header (via theUSE_X_FORWARDED_HOST setting) if your configuration requires it.

Session security

Similar to the CSRF limitations requiring a site to be deployed such that untrusted users don’t have access to any subdomains,django.contrib.sessions also has limitations. See the session topic guide section on security for details.

User-uploaded content

Note

Consider serving static files from a cloud service or CDN to avoid some of these issues.

• If your site accepts file uploads, it is strongly advised that you limit these uploads in your Web server configuration to a reasonable size in order to prevent denial of service (DOS) attacks. In Apache, this can be easily set using theLimitRequestBody directive.

• If you are serving your own static files, be sure that handlers like Apache’s mod_php, which would execute static files as code, are disabled. You don’t want users to be able to execute arbitrary code by uploading and requesting a specially crafted file.

• 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 libraries that Django uses for ImageField image processing (PIL or 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:

  1. One class of attacks can be prevented by always serving user uploaded content from a distinct Top Level Domain (TLD). This prevents any exploit blocked by 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 setting) from something likeusercontent-example.com. It’s not sufficient to serve content from a subdomain like usercontent.example.com.
  2. Beyond this, applications may choose to define a whitelist of allowable file extensions for user uploaded files and configure the web server to only serve such files.

Additional security topics

While Django provides good security protection out of the box, it is still important to properly deploy your application and take advantage of the security protection of the Web server, operating system and other components.

• Make sure that your Python code is outside of the Web server’s root. This will ensure that your Python code is not accidentally served as plain text (or accidentally executed).
• Take care with any user uploaded files.
• Django does not throttle requests to authenticate users. To protect against brute-force attacks against the authentication system, you may consider deploying a Django plugin or Web server module to throttle these requests.
• Keep your SECRET_KEY a secret.
• It is a good idea to limit the accessibility of your caching system and database using a firewall.