Django Book学习笔记（下）

Django的Session框架

对于Django加密，大致使用这样的格式：

hashtype$salt$hash

原因？

• 一次哈希是一次单向的加密过程，你能容易地计算出一个给定值的哈希码，但是几乎不可能从一个哈希码解出它的原值。
• 如果我们以普通文本存储密码,任何能进入数据库的人都能轻易的获取每个人的密码。 使用哈希方式来存储密码相应的减少了数据库泄露密码的可能。
• 然而，攻击者仍然可以使用 暴力破解 使用上百万个密码与存储的值对比来获取数据库密码。 这需要花一些时间，但是智能电脑惊人的速度超出了你的想象。
• 更糟糕的是我们可以公开地得到 rainbow tables （一种暴力密码破解表）或预备有上百万哈希密码值的数据库。 使用rainbow tables可以在几秒之内就能搞定最复杂的一个密码。
• 在存储的hash值的基础上，加入 salt 值（一个随机值），增加了密码的强度，使得破解更加困难。 因为每个密码的salt值都不相同，这也限制了rainbow table的使用，使得攻击者只能使用最原始的暴力破解方法。
• 加入salt值得hash并不是绝对安全的存储密码的方法，然而却是安全和方便之间很好的折衷。

 十.缓存机制

      我在Django中使用了Memcached，Memcached完全就是基于内存的缓存框架。Memcached有一个很好的特性是：它在多个服务器间分享缓存的能力。 这意味着您可以在多台机器上运行Memcached的守护进程，该程序会把这些机器当成一个单一缓存，而无需重复每台机器上的缓存值。 要充分利用此功能，请在CACHE_BACKEND里引入所有服务器的地址，用分号分隔。

      注意关于Memcached的一个缺点就是：基于内存的缓存有一个重大的缺点。 由于缓存的数据存储在内存中，所以如果您的服务器崩溃，数据将会消失。 显然，内存不是用来持久化数据的，因此不要把基于内存的缓存作为您唯一的存储数据缓存。 毫无疑问，在Django的缓存后端不应该用于持久化，它们本来就被设计成缓存的解决方案。但我们仍然指出此点，这里是因为基于内存的缓存是暂时的。

十一.Web开发中可能遇到的一些攻击及其防范

下面一大段来自复制粘贴，不喜勿喷：

SQL注入

• SQL注入 是一个很常见的形式，在SQL注入中，攻击者改变web网页的参数（例如 GET /POST 数据或者URL地址），加入一些其他的SQL片段。 未加处理的网站会将这些信息在后台数据库直接运行。
• 这种危险通常在由用户输入构造SQL语句时产生。 例如，假设我们要写一个函数，用来从通信录搜索页面收集一系列的联系信息。 为防止垃圾邮件发送器阅读系统中的email，我们将在提供email地址以前，首先强制用户输入用户名。

#无安全性的程序
def user_contacts(request):
    user = request.GET['username']
    sql = "SELECT * FROM user_contacts WHERE username = '%s';" % username
    # execute the SQL here...

如果攻击者在查询框中输入 "' OR 'a'='a" 。 此时，查询的字符串会构造如下：

SELECT * FROM user_contacts WHERE username = '' OR 'a' = 'a';

解决方案：
一些集成的web框架会自动帮你做好转义操作，总之别要轻易使用get方法（除非确定是对系统信息无害或者是自己已经做好了过滤的操作的情况下）

跨站点脚本 (XSS)

      在Web应用中， 跨站点脚本 (XSS)有时在被渲染成HTML之前，不能恰当地对用户提交的内容进行转义。 这使得攻击者能够向你的网站页面插入通常以 <script> 标签形式的任意HTML代码。    攻击者通常利用XSS攻击来窃取cookie和会话信息，或者诱骗用户将其私密信息透漏给被人（又称 钓鱼 ）。

      这种类型的攻击能够采用多种不同的方式，并且拥有几乎无限的变体，因此我们还是只关注某个典型的例子吧。 让我们来想想这样一个极度简单的Hello World视图：

from django.http import HttpResponse

def say_hello(request):
    name = request.GET.get('name', 'world')
    return HttpResponse('<h1>Hello, %s!</h1>' % name)

 这个视图只是简单的从GET参数中读取姓名然后将姓名传递给hello.html模板。 因此，如果我们访问 http://example.com/hello/?name=Jacob ，被呈现的页面将会包含一以下这些：

<h1>Hello, Jacob!</h1>

但是，等等，如果我们访问 http://example.com/hello/?name=<i>Jacob</i> 时又会发生什么呢？

<h1>Hello, <i>Jacob</i>!</h1>

当然，一个攻击者不会使用<i>标签开始的类似代码，他可能会用任意内容去包含一个完整的HTML集来劫持您的页面。 这种类型的攻击已经运用于虚假银行站点以诱骗用户输入个人信息，事实上这就是一种劫持XSS的形式，用以使用户向攻击者提供他们的银行帐户信息。

解决方案：

解决方案是简单的： 总是转义可能来自某个用户的任何内容。为了防止这种情况，Django的模板系统自动转义所有的变量值。

伪造跨站点请求

• 伪造跨站点请求(CSRF)发生在当某个恶意Web站点诱骗用户不知不觉的从一个信任站点下载某个URL之时，这个信任站点已经被通过信任验证，因此恶意站点就利用了这个被信任状态。
• Django拥有内建工具来防止这种攻击

会话劫持（无线wifi下由其注意的安全问题）

• 中间人攻击：检索所在有线（无线）网络，监听会话数据。
• 伪造会话 ：攻击者利用会话ID（可能是通过中间人攻击来获得）将自己伪装成另一个用户。
• 伪造cookie ：就是指某个攻击者覆盖了在某个cookie中本应该是只读的数据。
• 会话滞留 ：攻击者诱骗用户设置或者重设置该用户的会话ID。
• 会话中毒 ：攻击者通过用户提交设置会话数据的Web表单向该用户会话中注入潜在危险数据。