Django 安全

由 lxjazni_7 创建，小路依依 最后一次修改 2016-02-24 Internet并不安全。现如今，每天都会出现新的安全问题。 我们目睹过病毒飞速地蔓延，大量被控制的肉鸡作为武器来攻击其他人，与垃圾邮件的永无止境的军备竞赛，以及许许多多站点被黑的报告。作为Web开发人员，我们有责任来对抗这些黑暗的力量。 每一个Web开发者都应该把安全看成是Web编程中的基础部分。 不幸的是，要实现安全是困难的。Django试图减轻这种难度。 它被设计为自动帮你避免一些web开发新手（甚至是老手）经常会犯的错误。 尽管如此，需要弄清楚，Django如何保护我们，以及我们可以采取哪些重要的方法来使得我们的代码更加安全。首先，一个重要的前提： 我们并不打算给出web安全的一个详尽的说明，因此我们也不会详细地解释每一个薄弱环节。 在这里，我们会给出Django所面临的安全问题的一个大概。Web安全现状如果你从这章中只学到了一件事情，那么它会是：在任何条件下都不要相信浏览器端提交的数据。你从不会知道HTTP连接的另一端会是谁。 可能是一个正常的用户，但是同样可能是一个寻找漏洞的邪恶的骇客。从浏览器传过来的任何性质的数据，都需要近乎狂热地接受检查。 这包括用户数据（比如Web表单提交的内容）和带外数据（比如，HTTP头、cookies以及其他信息）。 要修改那些浏览器自动添加的元数据，是一件很容易的事。在这一章所提到的所有的安全隐患都直接源自对传入数据的信任，并且在使用前不加处理。 你需要不断地问自己，这些数据从何而来。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...备注在这个例子中，以及在以下所有的“不要这样做”的例子里，我们都去除了大量的代码，避免这些函数可以正常工作。 我们可不想这些例子被拿出去使用。尽管，一眼看上去，这一点都不危险，实际上却不尽然。首先，我们对于保护email列表所采取的措施，遇到精心构造的查询语句就会失效。 想象一下，如果攻击者在查询框中输入 "' OR 'a'='a" 。 此时，查询的字符串会构造如下：SELECT * FROM user_contacts WHERE username = '' OR 'a' = 'a';由于我们允许不安全的SQL语句出现在字符串中，攻击者加入 OR 子句，使得每一行数据都被返回。事实上，这是最温和的攻击方式。 如果攻击者提交了 "'; DELETE FROM user_contacts WHERE 'a' = 'a'" ，我们最终将得到这样的查询：SELECT * FROM user_contacts WHERE username = ''; DELETE FROM user_contacts WHERE 'a' = 'a';哦！我们整个通信录名单去哪儿了？ 我们整个通讯录会被立即删除解决方案尽管这个问题很阴险，并且有时很难发现，解决方法却很简单： 绝不信任用户提交的数据，并且在传递给SQL语句时，总是转义它。Django的数据库API帮你做了。 它会根据你所使用的数据库服务器（例如PostSQL或者MySQL）的转换规则，自动转义特殊的SQL参数。举个例子，在下面这个API调用中：foo.get_list(bar__exact="' OR 1=1")Django会自动进行转义，得到如下表达：SELECT * FROM foos WHERE bar = '\' OR 1=1'完全无害。这被运用到了整个Django的数据库API中，只有一些例外：传给 extra() 方法的 where 参数。 (参考 附录 C。) 这个参数故意设计成可以接受原始的SQL。使用底层数据库API的查询。 (详见第十章)以上列举的每一个示例都能够很容易的让您的应用得到保护。 在每一个示例中，为了避免字符串被篡改而使用绑定参数 来代替。这样，本节开始的例子应该写成这样：from django.db import connectiondef user_contacts(request): user = request.GET['username'] sql = "SELECT * FROM user_contacts WHERE username = %s" cursor = connection.cursor() cursor.execute(sql, [user]) # ... do something with the results底层 execute 方法采用了一个SQL字符串作为其第二个参数，这个SQL字符串包含若干’%s’占位符，execute方法能够自动对传入列表中的参数进行转义和插入。 你应该用 always 这种方式构造自定义的SQL。不幸的是，您并不是在SQL中能够处处都使用绑定参数，绑定参数不能够作为标识符（如表或列名等）。 因此，如果您需要这样做—我是说—动态构建 POST 变量中的数据库表的列表的话，您需要在您的代码中来对这些数据库表的名字进行转义。 Django提供了一个函数， django.db.backend.quote_name ，这个函数能够根据当前数据库引用结构对这些标识符进行转义。跨站点脚本 (XSS)在Web应用中， 跨站点脚本 (XSS)有时在被渲染成HTML之前，不能恰当地对用户提交的内容进行转义。 这使得攻击者能够向你的网站页面插入通常以  标签形式的任意HTML代码。攻击者通常利用XSS攻击来窃取cookie和会话信息，或者诱骗用户将其私密信息透漏给别人（又称 钓鱼 ）。这种类型的攻击能够采用多种不同的方式，并且拥有几乎无限的变体，因此我们还是只关注某个典型的例子吧。 让我们来想想这样一个极度简单的Hello World视图：from django.http import HttpResponsedef 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=Jacob 时又会发生什么呢？<h1>Hello, <i>Jacob</i>!</h1>当然，一个攻击者不会使用标签开始的类似代码，他可能会用任意内容去包含一个完整的HTML集来劫持您的页面。 这种类型的攻击已经运用