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';

哦�我们整个通信录��去哪儿了？

foo.get_list(bar__exact="' OR 1=1")

SELECT * FROM foos WHERE bar = '\' OR 1=1'

from django.db import connection

def 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

跨站点脚本 (XSS)

在Web应用中， 跨站点脚本 (XSS)有时在被渲染�HTML之�，�能�当地对用户�交的内容进行转义。这使得攻击者能够�你的网站页��入通常以 <script> 标签形�的任�HTML代�。

攻击者通常利用XSS攻击�窃�cookie和会�信�，或者诱骗用户将其�密信���给别人（�称 钓鱼 ）。

这�类型的攻击能够采用多���的方�，并且拥有几乎无�的�体，因此我们还是�关注�个典型的例��。让我们�想想这样一个�度简�的Hello World视图：

def say_hello(request):
    name = request.GET.get('name', 'world')
    return render_to_response("hello.html", {"name" : name})

这个视图�是简�的从GET�数中读�姓�然�将姓�传递给hello.html模�。我们�能会为这个视图编写如下所示的模�：

<h1>Hello, {{ name }}!</h1>

因此，如果我们访问 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的形�，用以使用户�攻击者�供他们的银行�户信�。

如果您将这些数��存在数�库中，然�将其显示在您的站点上，那么问题就�得更严�了。例如，一旦MySpace被�现这样的特点而能够轻易的被XSS攻击，�果�堪设想。�个用户�他的简介中�入JavaScript，使得您在访问他的简介页�时自动将其加为您的好�，这样在几天之内，这个人就能拥有上百万的好�。

现在，这��果�起�还�那么�劣，但是您�清楚——这个攻击者正设法将 他 的代�而�是MySpace的代��行在 您 的计算机上。这显然�背了�定信任——所有�行在MySpace上的代�应该都是MySpace编写的，而事实上��如此。

MySpace是�度幸�的，因为这些��代�并没有自动删除访问者的�户，没有修改他们的密�，也并没有使整个站点一团糟，或者出现其他因为这个弱点而导致的其他噩梦。

<h1>Hello, {{ name|escape }}!</h1>

伪造跨站点请求

伪造跨站点请求(CSRF)�生在当�个��Web站点诱骗用户�知�觉的从一个信任站点下载�个URL之时，这个信任站点已�被通过信任验�，因此��站点就利用了这个被信任状�。

Django拥有内建工具�防止这�攻击。这�攻击的介�和该内建工具都在第14章中进行进一步的�述。

会�伪造/劫�

这�是�个特定的攻击，而是对用户会�数�的通用类攻击。这�攻击�以采�多�形�：

中间人 攻击：在这�攻击中攻击者在监�有线（或者无线）网络上的会�数�。

伪造会� ：攻击者利用会�ID（�能是通过中间人攻击�获得）将自己伪装��一个用户。

这两�攻击的一个例��以是在一间咖啡店里的�个攻击者利用店的无线网络��获�个会�cookie，然�她就�以利用那个cookie��冒原始用户。

伪造cookie ：就是指�个攻击者覆盖了在�个cookie中本应该是�读的数�。第12章详细地解释了cookie的工作原�，cookie的一个显著特点就是�览者和��用户想�背�您�些修改，是一件很稀�平常的事情。

Web站点以 IsLoggedIn=1 或者 LoggedInAsUser=jacob 这样的方���存cookie由�已久，使用这样的cookie是�简��过的了。

但是，从更加细微的层��看，信任存储在cookie中的任何东西都从��是一个好主�，因为您从��知�多少人已�对它一清二楚。

会�滞留 ：攻击者诱骗用户设置或者�设置该用户的会�ID。

例如，PHP�许在URL（如 http://example.com/?PHPSESSID=fa90197ca25f6ab40bb1374c510d7a32 等）中传递会�标识符。攻击者诱骗用户点击�个带有硬编�会�ID的链接就会导致该用户��那个会�。

会�滞留已��用在钓鱼攻击中，以诱骗用户在攻击者拥有的账�里输入其个人信�，之�攻击者就能够登陆自己的�户�获�被骗用户输入的数�。

会�中毒 ：攻击者通过用户�交设置会�数�的Web表��该用户会�中注入潜在�险数�。

一个�典的例�就是一个站点在�个cookie中存储了简�的用户�好（比如一个页�背景颜色）。攻击者能够诱骗用户点击�个链接��交��颜色，而实际上链接中已�包�了�个XXS攻击，如果这个颜色没有被转义，攻击者就�以继续�该用户环境中注入��代�。

邮件头部注入

邮件头部注入 ：仅次于SQL注入，是一�通过劫���邮件的Web表�的攻击方�。攻击者能够利用这�技术�通过你的邮件�务器��垃圾邮件。在这�攻击��，任何方�的�自Web表�数�的邮件头部构筑都是�常脆弱的。

让我们看看在我们许多网站中�现的这�攻击的形�。通常这�攻击会�硬编�邮件地���一个消�，因此，第一眼看上去并�显得��对垃圾邮件那么脆弱。

但是，大多数表�都�许用户输入自己的邮件主题（�时还有from地�，邮件体，有时还有部分其他字段）。这个主题字段被用�构建邮件消�的主题头部。

如果那个邮件头部在构建邮件信�时没有被转义，那么攻击者�以�交类似 "hello\ncc:spamvictim@example.com" （这里的 "\n" 是�行符）的东西。这有�能使得所构建的邮件头部��：

To: hardcoded@example.com
Subject: hello
cc: spamvictim@example.com

就�SQL注入那样，如果我们信任了用户�供的主题行，那样�样也会�许他构建一个头部��集，他也就能够利用�系人表����垃圾邮件。

目录�历

目录�历 ：是�外一�注入方�的攻击，在这�攻击中，��用户诱骗文件系统代�对Web�务器�应该访问的文件进行读�和/或写入�作。

例��以是这样的，�个视图试图在没有仔细对文件进行防毒处�的情况下从�盘上读�文件：

def dump_file(request):
    filename = request.GET["filename"]
    filename = os.path.join(BASE_PATH, filename)
    content = open(filename).read()

    # ...

尽管一眼看上去，视图通过 BASE_PATH （通过使用 os.path.join ）�制了对于文件的访问，但如果攻击者使用了包� .. （两个��，父目录的一�简写形�）的文件�，她就能够访问到 BASE_PATH 目录结构以上的文件。�获���，�是一个时间上的问题（ ../../../../../etc/passwd ）。

任何��适当转义地读�文件�作，都�能导致这样的问题。�许 写 �作的视图�样容易�生问题，而且结果往往更加�怕。

这个问题的�一�表现形�，出现在根�URL和其他的请求信�动�地加载模�。一个众所周知的例��自于Ruby on Rails。在2006年上�年之�，Rails使用类似于 http://example.com/person/poke/1 这样的URL直接加载模�和调用函数。结果是，精心构造的URL，�以自动地调用任�的代�，包括数�库的清空脚本。

import os
import posixpath

# ...

path = posixpath.normpath(urllib.unquote(path))
newpath = ''
for part in path.split('/'):
    if not part:
        # strip empty path components
        continue

    drive, part = os.path.splitdrive(part)
    head, part = os.path.split(part)
    if part in (os.curdir, os.pardir):
        # strip '.' and '..' in path
        continue

    newpath = os.path.join(newpath, part).replace('\\', '/')

暴露错误消�

在开�过程中，通过�览器检查错误和跟踪异常是�常有用的。Django�供了漂亮且详细的debug信�，使得调试过程更加容易。

然而，一旦在站点上线以�，这些消��然被显示，它们就�能暴露你的代�或者是�置文件内容给攻击者。

还有，错误和调试消�对于最终用户而言是毫无用处的。Django的�念是，站点的访问者永远�应该看到与应用相关的出错消�。如果你的代�抛出了一个没有处�的异常，网站访问者�应该看到调试信�或者 任何 代�片段或者Python（��开�者）出错消�。访问者应该�看到�好的无法访问的页�。

当然，开�者需�在debug时看到调试信�。因此，框架就�将这些出错消�显示给�信任的网站开�者，而��公众��。

安全领域的总结

我们希望关于安全问题的讨论，�会太让你感到�慌。Web是一个处处布满陷阱的世界，但是��有一些远�，你就能拥有安全的站点。

永远记�，Web安全是一个�断�展的领域。如果你正在阅读这本书的�止维护的那些版本，请阅读最新版本的这个部分�检查最新�现的�洞。事实上，�周或者�月花点时间挖掘web应用安全，并且跟上最新的动�是一个很好的主�。��的投入，�能收获�护你的站点和用户的无价的回报。

接下�？

下一章中，我们会谈论到一些使用Django的细节问题：如何部署一个站点，并具有良好的伸缩性。