深入解析跨站请求伪造漏洞：原理剖析(1)

当存心不良的Web站点导致用户的浏览器在可信的站点上进行非意愿的活动时，我们就说发生了跨站请求伪造(CSRF)攻击。这些攻击被誉为基于Web的漏洞中的“沉睡的巨人”，因为互联网上的许多站点对此毫无防备，同时还因为这类攻击一直为web开发和安全社区所忽视。

一、概述

当存心不良的Web站点导致用户的浏览器在可信的站点上进行非意愿的活动时，我们就说发生了跨站请求伪造(CSRF)攻击。跨站请求伪造攻击亦称跨站引用伪造（XSRF），会话叠置和混淆代理人攻击。我们之所以使用术语CSRF，是因为它是描述这类攻击时最常用的术语。这些攻击被誉为基于Web的漏洞中的“沉睡的巨人”，因为互联网上的许多站点对此毫无防备，同时还因为这类攻击一直为Web开发社区和安全社区所忽视。目前，人们尚未将CSRF攻击列入Web安全威胁分类中，学术和技术文献也鲜有述及CSRF攻击者。CSRF攻击易于识别、易于利用同时也易于修补。它们之所以存在，是由于Web开发人员对CSRF攻击的根源和严重性的无知所致。Web开发人员也可能还误认为对更有名的跨站脚本（XSS）攻击的防御措施同时也能防御CSRF攻击。

在本文的下篇中将向读者介绍本年度在一些大型站点上发现的几个严重的CSRF漏洞，这些漏洞允许攻击者采集用户的电子邮件地址，侵犯用户隐私并操控用户帐户。同时，我们还将介绍对服务器端的改造方案，以便使站点能够全面防御的CSRF攻击。该方案有多种优点，这得益于它们不使用服务器的状态，同时不妨碍典型的web浏览活动。此外，我们也介绍了一个客户端的浏览器插件，它可以保护用户免受某些类型CSRF攻击。服务器端保护措施能使站点本身具备完全防御CSRF攻击的能力，而客户端保护措施使用户未雨绸缪，提前采取防疫措施，以便在站点没有采取防护措施的情况下也能够免受CSRF攻击。尽管现在Web开发人员已经有了防御此类攻击的工具，但是仍希望大家能提高对CSRF攻击的防范意识。

二、跨站请求伪造攻击原理

为了便于读者对于跨站请求伪造漏洞的原理，下面我们用图例进行解释。图1、图2和图3为大家介绍了CSRF攻击的一般原理。

图1 浏览器和网站建立认证的会话

这里，Web浏览器已经跟可信的站点建立了一个经认证的会话。之后，只要是通过该Web浏览器这个认证的会话所发送的请求，都被视为可信的动作。

图2 浏览器发送有效的请求

上图中，浏览器正在发送一个有效的请求，即Web浏览器企图执行一个可信的动作。可信的站点经确认发现，该Web浏览器已通过认证，所以该动作将被执行。

图3 恶意站点伪造的有效请求

上图中，发生了一个CSRF攻击。发起攻击的站点致使浏览器向可信的站点发送一个请求。该可信的站点认为，来自该Web浏览器的请求都是经过认证的有效请求，所以执行这个“可信的动作”。CSRF攻击之所以会发生，其根本原因就是Web站点所验证的是Web浏览器而非用户本身。下面我们用一个具体的示例来详细介绍CSRF攻击。

假设某个站点存在CSRF攻击漏洞，比如一个基于Web的电子邮件网站，用户通过该站点可以发送和接收电子邮件。该站点利用隐式认证方式来验证用户身份，它的某个页面，如http://example.com/compose.htm包含一个供用户输入收信人的电子邮件地址、主题和消息的HTML表单，以及一个名为“Send Email”的按钮。

{form action="http://example.com/send_email.htm" method="GET"} Recipient’s Email address: {input type="text" name="to"} Subject: {input type="text" name="subject"} Message: {textarea name="msg"}{/textarea} {input type="submit" value="Send Email"} {/form}

:当example.com站点的用户单击“Send Email”时，该用户输入的数据就会通过一个GET请求发送到http://example.com/send_email.htm。由于GET请求只是简单地将表单数据附加到URL上，所以用户发送的URL如下所示。这里假设该用户输入的收信人为“bob@example.com”，主题为“hello”，消息为“What’s
your name?”：

http://example.com/send_email.htm?to=bob%40example.com&subject=hello&msg=What%27s+your+name%3F

需要注意的是，上面的URL的数据已经过编码，@被转换成%40，等等。

根据收到的数据向用户指定的收信人发送一封电子邮件。注意，send_email.htm所做的只是提取数据，随后用该数据完成一个动作。它并不理会该请求来自哪里，它唯一关心的是收到的请求。这意味着，即使上述URL是用户手动输入到他的浏览器的，那么example.com也照常发送一封电子邮件。例如，如果该用户在其浏览器地址栏中键入了下列三个URL，那么send_email.htm页面将三封电子邮件（分别发给Bob、Alice和Carol ）：

http://example.com/send_email.htm?to=bob%40example.com&subject=hi+Bob&msg=test http://example.com/send_email.htm?to=alice%40example.com&subject=hi+Alice&msg=test http://example.com/send_email.htm?to=carol%40example.com&subject=hi+Carol&msg=test

这里会出现CSRF攻击，原因是send_email.htm会把收到的数据悉数提取，然后发电子邮件。它没有对自compose.htm页面的表单中的数据进行检验。因此，攻击者只要设法让用户向send_email.htm发送一个请求，那么send_email.htm这个页面就会引起example.com发送一封电子邮件，要紧的是，该邮件是以该用户名义发送的，并且包含的是攻击者任意选择的任何数据，这样攻击者就成功地进行了一次CSRF攻击。

为了利用这个弱点，攻击者需要强迫用户的浏览器向send_email.htm发送一个请求来完成一些邪恶的动作。我们假定用户浏览了一个为攻击者所控制的站点，并且目标站点没有采取针对CSRF攻击的防御措施。具体地说，攻击者需要伪造一个跨站请求，该请求的发源地是从他的站点，目的地为example.com，中间会路过受害者的浏览器。令人遗憾的是，HTML为制造这种请求提供了多种方式。例如，浏览器遇到标签时，任何被设置为src属性的URI都会被加载，即使那个URI不是一幅图像。攻击者可以用以下代码创建一个页面：

{img src="http://example.com/send_email.htm?to=mallory%40example.com&subject=Hi&msg=My+email+address+has+been+stolen"}

当用户访问这个页面时，一个请求被发送到send_email.htm，然后，将有一封来自该用户的电子邮件被发送给Mallory。这个例子跟后面将要介绍的纽约时报站点上发现的漏洞几乎完全一致。

要想成功发动CSRF攻击，攻击者只要能够引起用户的浏览器在另一个站点上执行一个非本意的动作即可，当然前提是用户必须有执行该动作的权限。CSRF攻击能获取跟用户一样大的权限，即任何用户可以执行的动作，攻击者利用CSRF攻击也能完成。所以，站点赋予用户的权限越大，受到CSRF攻击的可能性就越高，CSRF攻击带来的后果也越严重。

对于所有使用隐式的认证方式并且没有采取显式的针对CSRF攻击的自我保护措施的站点，CSRF攻击几乎总能得手。