The Django Book

The Theme of Web Security

Web安全现状

If you learn only one thing from this chapter, let it be this:

如果你从这章中�学到了一件事情，那么它会是：

Never under any circumstances trust data from the browser.

在任何�件下都��相信�览器端�交的数�。

You never know whos on the other side of that HTTP connection. It might be one of your users, but it just as easily could be a nefarious cracker looking for an opening.

你从�会知�HTTP连接的�一端会是�。�能是一个正常的用户，但是�样�能是一个寻找�洞的邪�的骇客。

Any data of any nature that comes from the browser needs to be treated with a healthy dose of paranoia. This includes data thats both in band (i.e., submitted from Web forms) and out of band (i.e., HTTP headers, cookies, and other request information). Its trivial to spoof the request metadata that browsers usually add automatically.

从�览器传过�的任何性质的数�，都需�近乎狂热地接�检查。这包括用户数�（比如web表��交的内容）和带外数�（比如，HTTP头�cookies以�其他信�）。�修改那些�览器自动添加的元数�，是一件很容易的事。

Every one of the vulnerabilities discussed in this chapter stems directly from trusting data that comes over the wire and then failing to sanitize that data before using it. You should make it a general practice to continuously ask, Where does this data come from?

在这一章所�到的所有的安全�患都直接�自对传入数�的信任，并且在使用��加处�。你需��断地问自己，这些数�从何而�。

SQL Injection

SQL注入

SQL injection is a common exploit in which an attacker alters Web page parameters (such as GET /POST data or URLs) to insert arbitrary SQL snippets that a naive Web application executes in its database directly. Its probably the most dangerous and, unfortunately, one of the most common vulnerabilities out there.

SQL注入 是一个很常�的形�，在SQL注入中，攻击者改�web网页的�数（例如 GET /POST 数�或者URL地�），加入一些其他的SQL片段。未加处�的网站会将这些信�在��数�库直接�行。这也许是最�险的一�，然而�幸的是，也是最多的一��患。

This vulnerability most commonly crops up when constructing SQL by hand from user input. For example, imagine writing a function to gather a list of contact information from a contact search page. To prevent spammers from reading every single email in our system, well force the user to type in someones username before providing her email address:

这��险通常在由用户输入构造SQL语�时产生。例如，�设我们�写一个函数，用�从通信录�索页�收集一系列的�系信�。为防止垃圾邮件��器阅读系统中的email，我们将在�供email地�以�，首先强制用户输入用户�。

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

Note

备注

In this example, and all similar dont do this examples that follow, weve deliberately left out most of the code needed to make the functions actually work. We dont want this code to work if someone accidentally takes it out of context.

在这个例�中，以�在以下所有的“��这样��的例�里，我们都去除了大�的代�，��这些函数�以正常工作。我们��想这些例�被拿出去使用。

Though at first this doesnt look dangerous, it really is.

尽管，一眼看上去，这一点都��险，实际上��尽然。

First, our attempt at protecting our entire email list will fail with a cleverly constructed query. Think about what happens if an attacker types "' OR 'a'='a" into the query box. In that case, the query that the string interpolation will construct will be:

首先，我们对于�护email列表所采�的措施，�到精心构造的查询语�就会失效。想象一下，如果攻击者在查询框中输入 "' OR 'a'='a" 。此时，查询的字符串会构造如下：

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

Because we allowed unsecured SQL into the string, the attackers added OR clause ensures that every single row is returned.

由于我们�许�安全的SQL语�出现在字符串中，攻击者加入 OR ��，使得�一行数�都被返回。

However, thats the least scary attack. Imagine what will happen if the attacker submits "'; DELETE FROM user_contacts WHERE 'a' = 'a'" . Well end up with this complete query:

事实上，这是最温和的攻击方�。如果攻击者�交了 "'; DELETE FROM user_contacts WHERE 'a' = 'a'" ，我们最终将得到这样的查询：

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

Yikes! Whered our contact list go?

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

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

Cross-Site Scripting (XSS)

跨站点脚本 (XSS)

Cross-site scripting (XSS), is found in Web applications that fail to escape user-submitted content properly before rendering it into HTML. This allows an attacker to insert arbitrary HTML into your Web page, usually in the form of <script> tags.

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

Attackers often use XSS attacks to steal cookie and session information, or to trick users into giving private information to the wrong person (aka phishing ).

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

This type of attack can take a number of different forms and has almost infinite permutations, so well just look at a typical example. Consider this extremely simple Hello, World view:

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

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

This view simply reads a name from a GET parameter and passes that name to the hello.html template. We might write a template for this view as follows:

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

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

So if we accessed http://example.com/hello/name=Jacob , the rendered page would contain this:

因此，如果我们访问 http://example.com/hello/?name=Jacob ，被呈现的页�将会包�一以下这些：

<h1>Hello, Jacob!</h1>

But wait what happens if we access http://example.com/hello/name=<i>Jacob</i> ? Then we get this:

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

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

Of course, an attacker wouldnt use something as benign as <i> tags; he could include a whole set of HTML that hijacked your page with arbitrary content. This type of attack has been used to trick users into entering data into what looks like their banks Web site, but in fact is an XSS-hijacked form that submits their back account information to an attacker.

当然，一个攻击者�会使用<i>标签开始的类似代�，他�能会用任�内容去包�一个完整的HTML集�劫�您的页�。这�类型的攻击已��用于虚�银行站点以诱骗用户输入个人信�，事实上这就是一�劫�XSS的形�，用以使用户�攻击者�供他们的银行�户信�。

The problem gets worse if you store this data in the database and later display it it on your site. For example, MySpace was once found to be vulnerable to an XSS attack of this nature. A user inserted JavaScript into his profile that automatically added him as your friend when you visited his profile page. Within a few days, he had millions of friends.

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

Now, this may sound relatively benign, but keep in mind that this attacker managed to get his code not MySpaces running on your computer. This violates the assumed trust that all the code on MySpace is actually written by MySpace.

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

MySpace was extremely lucky that this malicious code didnt automatically delete viewers accounts, change their passwords, flood the site with spam, or any of the other nightmare scenarios this vulnerability unleashes.

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

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

Cross-Site Request Forgery

伪造跨站点请求

Cross-site request forgery (CSRF) happens when a malicious Web site tricks users into unknowingly loading a URL from a site at which theyre already authenticated hence taking advantage of their authenticated status.

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

Django has built-in tools to protect from this kind of attack. Both the attack itself and those tools are covered in great detail in Chapter 14.

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

Session Forging/Hijacking

会�伪造/劫�

This isnt a specific attack, but rather a general class of attacks on a users session data. It can take a number of different forms:

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

A man-in-the-middle attack, where an attacker snoops on session data as it travels over the wire (or wireless) network.

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

Session forging , where an attacker uses a session ID (perhaps obtained through a man-in-the-middle attack) to pretend to be another user.

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

An example of these first two would be an attacker in a coffee shop using the shops wireless network to capture a session cookie. She could then use that cookie to impersonate the original user.

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

A cookie-forging attack, where an attacker overrides the supposedly read-only data stored in a cookie. Chapter 12 explains in detail how cookies work, and one of the salient points is that its trivial for browsers and malicious users to change cookies without your knowledge.

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

Theres a long history of Web sites that have stored a cookie like IsLoggedIn=1 or even LoggedInAsUser=jacob . Its dead simple to exploit these types of cookies.

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

On a more subtle level, though, its never a good idea to trust anything stored in cookies; you never know whos been poking at them.

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

Session fixation , where an attacker tricks a user into setting or reseting the users session ID.

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

For example, PHP allows session identifiers to be passed in the URL (e.g., http://example.com/?PHPSESSID=fa90197ca25f6ab40bb1374c510d7a32 ). An attacker who tricks a user into clicking a link with a hard-coded session ID will cause the user to pick up that session.

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

Session fixation has been used in phishing attacks to trick users into entering personal information into an account the attacker owns. He can later log into that account and retrieve the data.

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

Session poisoning , where an attacker injects potentially dangerous data into a users session usually through a Web form that the user submits to set session data.

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

A canonical example is a site that stores a simple user preference (like a pages background color) in a cookie. An attacker could trick a user into clicking a link to submit a color that actually contains an XSS attack; if that color isnt escaped, the user could again inject malicious code into the users environment.

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

Email Header Injection

邮件头部注入

SQL injections less well-known sibling, email header injection , hijacks Web forms that send email. An attacker can use this technique to send spam via your mail server. Any form that constructs email headers from Web form data is vulnerable to this kind of attack.

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

Lets look at the canonical contact form found on many sites. Usually this sends a message to a hard-coded email address and, hence, doesnt appear vulnerable to spam abuse at first glance.

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

However, most of these forms also allow the user to type in his own subject for the email (along with a from address, body, and sometimes a few other fields). This subject field is used to construct the subject header of the email message.

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

If that header is unescaped when building the email message, an attacker could submit something like "hello\ncc:spamvictim@example.com" (where "\n is a newline character). That would make the constructed email headers turn into:

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

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

Like SQL injection, if we trust the subject line given by the user, well allow him to construct a malicious set of headers, and he can use our contact form to send spam.

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

Directory Traversal

目录�历

Directory traversal is another injection-style attack, wherein a malicious user tricks filesystem code into reading and/or writing files that the Web server shouldnt have access to.

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

An example might be a view that reads files from the disk without carefully sanitizing the file name:

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

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

    # ...

Though it looks like that view restricts file access to files beneath BASE_PATH (by using os.path.join ), if the attacker passes in a filename containing .. (thats two periods, a shorthand for the parent directory), she can access files above BASE_PATH . Its only a matter of time before she can discover the correct number of dots to successfully access, say, ../../../../../etc/passwd .

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

Anything that reads files without proper escaping is vulnerable to this problem. Views that write files are just as vulnerable, but the consequences are doubly dire.

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

Another permutation of this problem lies in code that dynamically loads modules based on the URL or other request information. A well-publicized example came from the world of Ruby on Rails. Prior to mid-2006, Rails used URLs like http://example.com/person/poke/1 directly to load modules and call methods. The result was that a carefully constructed URL could automatically load arbitrary code, including a database reset script!

这个问题的�一�表现形�，出现在根�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('\\', '/')

Exposed Error Messages

暴露错误消�

During development, being able to see tracebacks and errors live in your browser is extremely useful. Django has pretty and informative debug messages specifically to make debugging easier.

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

However, if these errors get displayed once the site goes live, they can reveal aspects of your code or configuration that could aid an attacker.

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

Furthermore, errors and tracebacks arent at all useful to end users. Djangos philosophy is that site visitors should never see application-related error messages. If your code raises an unhandled exception, a site visitor should not see the full traceback or any hint of code snippets or Python (programmer-oriented) error messages. Instead, the visitor should see a friendly This page is unavailable message.

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

Naturally, of course, developers need to see tracebacks to debug problems in their code. So the framework should hide all error messages from the public, but it should display them to the trusted site developers.

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

A Final Word on Security

安全领域的总结

We hope all this talk of security problems isnt too intimidating. Its true that the Web can be a wild and wooly world, but with a little bit of foresight, you can have a secure Web site.

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

Keep in mind that Web security is a constantly changing field; if youre reading the dead-tree version of this book, be sure to check more up to date security resources for any new vulnerabilities that have been discovered. In fact, its always a good idea to spend some time each week or month researching and keeping current on the state of Web application security. Its a small investment to make, but the protection youll get for your site and your users is priceless.

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

Whats Next

接下�？

In the next chapter, well finally cover the subtleties of deploying Django: how to launch a production site and how to set it up for scalability.

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