本节主要是讲解django中的安全特性，讲述django是如何应对网站一般面临的安全性问题
跨站点脚本（XXS）攻击
跨站点脚本攻击是指一个用户把客户端脚本注入到其他用户的浏览器中。通常是通过在数据库中存储恶意的脚本，当这些脚本被检索然后展示给其他用户时实现的攻击的，或者诱使 用户点击攻击者的那些会被用户浏览器运行的脚本。django是如何应付的呢？
django的模板系统可以预防大部分的XXS攻击，然而我们要知道，django预防了那些，还有那些是预防不了的：django模板使用了”转义特殊字符“的方法转义了那些对html有危险的字符，然而，这不是一劳永逸的：
<style class={{ var }}>...</style>
假如var的值是class1 οnmοuseοver=javascript:func()呢？这取决于浏览器如何处理这个不合法的html的了？
因此，当一定要在数据库中存储html的时候，请特别注意保证安全性，特别是这些html会被检索然后呈现给用户的时候！
跨站点请求伪造（CSRF）攻击
csrf攻击是在用户不知情的情况下，该用户的凭据被恶意的用户使用去执行某些动作。
django有内建的措施预防大多数类型的csrf攻击，然而，每一种预防的措施都会有自己的缺陷，比如你的站点有一些不在你控制范围的子站点。
除非万不得已，否则请不要使用csrf_exemp装饰器。
SQL注入攻击
SQL攻击是指恶意的用户可以在一个数据库上执行任意的SQL代码，这可能会带来数据丢失，删除甚至崩溃。
通过django的queryset，产生的SQL将被底层数据库驱动程序正确转义。然而，django也提供开发者写原生的查询和运行自定义的sql，这些都是隐患。
Clickjacking点击劫持
你有没有遇到过这样的情况，打开一个网页，出现一个flash广告框，你点击“关闭”按钮，可结果广告并没有关闭，却变成了全屏，这样的情况在计算机安全领域叫做点击劫持，也就是说你点击鼠标的行为被人给控制了。django的X-Frame-Options 中间件保护一个站点不被渲染成一个框架（html的frame），从而预防了点击劫持。
所以，任何没有必要在第三方站点被封装成框架的站点都应该启用这个中间件。
SSL/HTTPS
能安全总是更好的，尽管有时候并不实际。主要不是安全连接HTTPS，还是会有风险的，无论是认证凭据被截获还是客户端与服务器端的其他信息被转换，还是其他。
如果你想启用HTTPS，这是一些额外的需要配置：（这个配置我自己没有实现过，仅供参考，或许需要的时候我们可以私下讨论一下）
- 如果需要，设置SECURE_PROXY_SSL_HEADER
- 设置重定向，以方便HTTP可以转到HTTPS
- 使用安全的cookie
主机头部验证
有些情况下，django使用Host头部去构造一些url，这些值在XXS攻击下是安全的，当对于CSRF，缓存中毒，毒性链接等时却不一定了。
因为这些看似安全的服务器，还是有伪装头部的嫌疑的。django通过对比ALLOWED_HOST和django.http.HttpRequest.get_host()来验证一个Host头部，记住，仅仅get_host方法是安全的，如果你仅仅使用request.META中的内容来校验host头部，那么你已经置django的安全防护于不顾了
其他的安全问题
尽管django提供了很多的安全防护措施，但恰当的开发自己的应用和使用web服务器，操作系统和其他的组件的有用之处也是很重要的：
- 确保你的python代码不在web服务器的根目录，这可以确保你的python代码不会被意外执行
- 小心“用户上传的文件”
- django不限制请求来验证用户身份，因此，为了避免认证系统遭受暴力攻击，你可能需要开发django插件或者web服务器模块来限制这些请求
- 如果你的站点接受文件上传，请保证对这些上传有所控制以避免拒绝服务攻击（DOS），比如控制文件的大小
- 不要泄露你的SECRET_KEY
- 通过使用防火墙来限制你的缓存和数据库的访问
