基于Django的安全性学习（上）
防御跨站脚本攻击（XSS）
-
发起 XSS 攻击的人可以向其他用户的浏览器诸如客户端脚本。这种攻击通常由存储在数据库中的恶意脚本实现，这些脚本会被检索出来并显示给其他用户；或者通过其他用户点击会令攻击者的 JavaScript 脚本在浏览器中执行的链接来实现。
-
对于 HTML 来说，Django 模板中的 转义特殊字符 是尤其危险的。虽然它保护用户免受大多数恶意输入的攻击，但并非万无一失。比如，出现下面这种情况就会保护失效：
<style class={{ var }}>...</style>
- 如果 var 被设置为 'class1 onmouseover=javascript:func()' ，将导致未经授权的 JavaScript 脚本执行，这取决于浏览器如何渲染有缺陷的HTML。（引用属性值可以解决这个问题）
与此不相上下的还有在使用带有自定义模板标签的 is_safe ，safe 模板标签，mark_safe，以及关闭自动转义时要特别小心。
此外，如果使用模板系统输出了除 HTML 之外的内容，可能会有完全独立的字符和单词需要转义。
防御跨站点请求伪造（CSRF）
- 发起 CSRF 攻击的人可以使用其他用户的证书执行操作，且是在其不知情或不同意的情况下。
- Django 内置了保护措施来防御大多数 CSRF 攻击，但和多数缓解性技术一样，它是有局限性的。比如可以全局禁用 CSRF 模块或者特定的视图。
CSRF 保护机制 通过检查每一个 POST 请求中的密文来实现。这保证恶意用户不能“复现”一个表单并用 POST 提交到网页，并让一个已登录用户无意中提交该表单。恶意用户必须知道特定于用户的密文（使用 cookie）。
在部署 HTTPS 时，CsrfViewMiddleware 会检查 HTTP 报文的 referer 首部是否设置为同源的 URL（包括子域和端口）。因为 HTTPS 提供了额外的安全性，所有通过转发不安全连接请求并在支持的浏览器中使用 HSTS 来确保连接在可用的地方使用了 HTTPS ，这一点是很重要的。
防御 SQL 注入
-
SQL 注入能让恶意用户能在数据库中执行任意 SQL 代码。这将导致记录被删除或泄露。
-
Django 的 querysets 在被参数化查询构建出来时就被保护而免于 SQL 注入。查询的 SQL 代码与查询的参数是分开定义的。参数可能来自用户从而不安全，因此它们由底层数据库引擎进行转义。
Django 也提供了书写原始查询或执行自定义 sql 的权力。
防御访问劫持
-
访问劫持能让恶意网页覆盖另一个网页。可能会有毫不知情的用户被骗入目标网页并执行意料之外的操作。
-
Django 包含访问劫持保护 ，以 X-Frame-Options middleware 的形式在支持它的浏览器中阻止一个网页被渲染在 frame 的内部。可在每个视图的基础上禁用保护，也可配置发送的确切头部值。
对于任何不会被第三方网站嵌入 frame 的网页，或者只允许使用一小部分的网页来说，强烈建议使用中间件。