深刻解析跨站请求伪造漏洞：原理剖析

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

1、概述

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

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

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

为了便于读者对于跨站请求伪造漏洞的原理，下面咱们用图例进行解释。图一、图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攻击几乎总能得手。

3、跨站请求伪造漏洞的根本缘由

CSRF攻击常常利用目标站点的身份验证机制，CSRF攻击这一弱点的根源在于Web的身份验证机制虽然能够向目标站点保证一个请求来自于某个用户的浏览器，可是却没法保证该请求的确是那个用户发出的或者是通过那个用户批准的。例如，假如Alice在浏览目标站点T，那么站点T便会给Alice的浏览器一个cookie，用于存放一个伪随机数做为会话标识符sid，以跟踪她的会话。该站点会要求Alice进行登陆，当她输入有效的用户名和口令时，该站点会记录这样一个事实：Alice已经登陆到会话sid。当Alice发送一个请求到站点T时，她的浏览器就会自动地发送包含sid的会话cookie。以后，站点T就会使用站点的会话记录来识别该会话是否来自Alice。

如今，咱们假设Alice访问了一个恶意站点M，该站点提供的内容中的JavaScript代码或者图像标签会致使Alice的浏览器向站点T发送一个HTTP请求。因为该请求是发给站点T的，因此Alice的浏览器自动地给该请求附上与站点T对应的该会话cookie的sid。站点T看到该请求时，它就能经过该cookie的推断出：该请求来自Alice，因此站点T就会对Alice的账户执行所请求的操做。这样，CSRF攻击就能得逞了。

其余大多数Web认证机制也面临一样的问题。例如，HTTP BasicAuth机制会要求Alice告诉浏览器她在站点T上的用户名和口令，因而浏览器将用户名和口令附加到以后发给站点T的请求中。固然，站点T也可能使用客户端SSL证书，但这也面临一样的问题，由于浏览器也会将证书附加到发给站点T的请求中。相似的，若是站点T经过IP地址来验证Alice的身份的话，照样面临CSRF攻击的威胁。

总之，只要身份认证是隐式进行的，就会存在CSRF攻击的危险，由于浏览器发出请求这一动做未必是受用户的指使。原则上，这种威胁能够经过对每一个发送至该站点的请求都要求用户进行显式的、不可欺骗的动做（诸如从新输入用户名和口令）来消除，但实际上这会致使严重的易用性问题。大部分标准和普遍应用的认证机制都没法防止CSRF攻击，因此咱们只好另外探求一个实用的解决方案。

4、CSRF攻击向量

成功发动攻击前提是，用户必须已经登陆到目标站点，而且必须浏览了攻击者的站点或被攻击者部分控制的站点。若是一个服务器有CSRF漏洞，而且接受GET请求（就像上面的例子那样），那么无需使用JavaScript就能够发动CSRF攻击，例如，只需使用{IMG}标签就能够搞定。若是该服务器仅接受POST请求，那么要想从攻击者的站点自动发送POST请求到目标站点的话，就必须使用JavaScript。

5、CSRF与XSS

近来，跨站脚本攻击（XSS）漏洞引发了人们的普遍注意。XSS攻击一般是指，攻击者向一个站点注入恶意代码（一般为JavaScript），以攻击该站点的其它用户（即攻击的最终目标并不是站点自己）。例如，站点可能容许用户发表评论，这样的话，评论由用户张贴，而后被存储在站点的数据库中，最后会展现给该站点的全部用户。若是攻击者能在评论中夹杂上恶意JavaScript代码的话，那么这些JavaScript代码就会嵌入到全部包含该评论的页面中。当一个用户访问该站点时，攻击者的JavaScript代码就被执行，执行权限具备目标站点一切特权。嵌入目标站点的恶意JavaScript代码将能发送和接收来自该站点上的任何页面的请求，并可以访问由该站点设置的cookie。要想防护XSS 攻击，站点必须仔细过滤全部的用户输入，以确保不被注入恶意代码。

CSRF和XSS攻击的区别在于，XSS攻击须要JavaScript，而CSRF攻击不须要；XSS攻击要求站点接受恶意代码，而对于CSRF攻击来讲，恶意代码位于第三方站点上。过滤用户的输入能够防止恶意代码注入到某个站点，可是它无阻止法恶意代码在第三方站点上运行。因为恶意代码能够在第三方站点上运行，因此防护XSS攻击的措施没法保护站点不受CSRF攻击的危害。若是站点具备XSS攻击漏洞，那么它也有CSRF攻击漏洞。可是，即便站点针对XSS攻击采起了全面保护，却仍然面临CSRF攻击的威胁。

上面介绍了跨站请求伪造的原理、安全问题的根本缘由、攻击手法和与跨站脚本攻击之间的区别，下面咱们看看现有的安全策略是否可以防护这种攻击。

6、同源策略与跨站请求伪造

Web浏览器有一项艰巨的任务，那就是容许用户维护到达多个网站的安全的专用连接，同时还容许访问包含不可信代码的不可信的站点。另外，站点可以从不一样的域加载资源。举例来讲，站点a.com 可以分别使用{IMG}或者 {SCRIPT} 标签从b.com加载图象或者JavaScript。然而，若是用户已经登陆到一个可信的站点，那么固然不该该让不可信的第三方站点读取可信的站点的内容。

为了可以在容许不可信的站点显示来自外部站点的数据的同时还能保持这些数据的私密性，人们建立了同源策略。该策略不只定义了“源”的含义，还规定了当访问来自不一样源的数据时，站点能作哪些事情。该策略认为，若是两个页面的协议、端口（若是给出的话）和主机彻底一致，那么就说这两个页面是同源的。根据同源策略的规定，站点不能读取或者修改来自不一样的源的资源。

然而，该策略却容许向不一样源请求资源。所以，evil.com 能够在它的站点中经过{IMG}标签包含图像http://trusted.com/image.gif，可是它不可以读取这幅图像的像素。一样的，evil.com也能够在他的站点内利用{iframe}标签来包含http://trusted.com/private.htm ，可是evil.com却不能访问或者修改浏览器显示的这个页面的内容。

同源策略仅仅阻止了第三方站点读取来自其余站点的内容，可是却没有防止这些第三方站点向其余站点发出请求。由于CSRF攻击是因为某些请求被发出（而引发在服务器端执行了某些动做）所引发的，因此同源策略只能用来保护第三方站点上的数据的私密性，可是同源策略没法防止CSRF攻击。

7、跨域策略与跨站请求伪造

对于有些站点来讲，进行跨域通讯是很是有用的，有时候甚至的必不可少的。鉴于此，Adobe提出了一个机制，称为跨域策略，该策略在某些状况下能够容许它的Flash插件跟不一样的域进行通讯即发送和接收数据。该机制当前只用于Flash，具体地说，站点可以规定哪些第三方站点能够访问它。第三方站点只能跟其跨域策略文件中规定的第三方站点进行联络。下面的跨域策略文件容许访问源自www.friendlysite.com、*.trusted .com 和IP地址64.233.167.99的请求。这些文件被命名为crossdomain.xml并放在该域的根目录下。

{?xml version="1.0"?}{cross-domain-policy}
domain="www.friendlysite.com" /}
{allow-access-from domain="*.trusted.com" /}
{allow-access-from domain="64.233.167.99" /}
{/cross-domain-policy}

假设以上文件位于http://trusted.com/crossdomain.xml。若是evil.com使用Flash向http://trusted.com/private.htm发出了一个请求，Flash将首先加载http://trusted.com/crossdomain.xml以检验evil.com是否已做为受信任的域列于其中。由于它没有列于其中，因此该请求就会被阻止。相反，若是同一请求来自www.friendlysite.com的话，则Flash将容许该请求，这是由于www.friendlysite.com已经位于被许可的列表中了。

若是使用恰当的话，Adobe的跨域策略可以比同源策略（除非在crossdomain.xml中找到匹配，不然该请求没法启动）更好地防护CSRF攻击，而且具备更高的灵活性（若是目标站点信任发起方站点即源站点的话，则容许跨域通讯）。 然而，跨域策略常常被不正确使用，好比将一个目标站点放到“accept all”的条款中，这会容许第三方从任何站点（无论这个站点是善意的仍是恶意的）访问它。甚至Adobe的联盟站点crossdomainxml.org的crossdomain.xml文件也出现了不适当甚至极度危险的用法：域名crossdomainxml.org被注册到TPowerSDK Software 有限公司的heodore E Patrick名下，该公司在其LinkedIn profile（http://www.linkedin.com/in/tedpatrick）中写道他们是Adobe Systems的Flex的技术布道者。 这个站点提供了“accept all ”跨域策略文件的例子，使用该文件的危险性不言自明。

安全研究人员曾经对世界500强的网站进行了分析，其中发现有143个站点使用了crossdomain.xml策略文件。而在这143个站点中，又有47个站点对来自第三方站点的连接彻底接受，这可能致使CSRF漏洞。Adobe的跨域策略多是有效和安全的，但前提是要当心使用。若是在策略文件中使用了“accept all”的话，结果是很是严重的。

8、P3P与跨站请求伪造

Cookie可用于在站点之间跟踪用户，举例来讲，若是登广告者在他的服务器上寄放了一张图片（即广告），而他的服务器将被大量广告发行站点所引用。当该图像被显示时，登广告者能够设置一个cookie，这样，当同一个用户访问不一样的广告发布站点时，登广告者也能认出他是同一我的。换句话说，当该用户访问一个广告发布者的站点并加载登广告者的图像时，该用户的cookie会发回给登广告者，因为该cookie是惟一的，因此登广告者可以识别该用户。登广告者可使用这些Cookie来收集有关该用户上网的习惯的数据。

Cookie在用户隐私方面的负面影响致使了“隐私权偏好选项平台” (Platform for Privacy Preferences，P3P)的出现。P3P“提供了通用的语法和传输机制，使得Web站点可以将网站对客户隐私的处理状况传达给Internet Explorer 6(或者其余任何用户代理)”。从Internet Explorer 6起，微软公司开始要求全部站点包含一个P3P策略，以便判断接受第三方Cookie。

按照微软公司的说法：

先进的cookie过滤技术，会对Web 站点的隐私作法进行评测，并根据站点的策略跟用户设置的比较结果来决定接受哪些Cookie。根据默认设置，用于收集我的标识信息的Cookie和不容许用户进行选择的Cookie被认为是“不能使人满意的”。默认时,将在浏览结束时把第一方中的不能使人满意的Cookie删掉，并拒绝第三方环境中不能使人满意的Cookie。（注意，P3P政策没有进行验证。因此若是一个站点要求具备一项可接受的政策，Internet Explorer就会容许第三方Cookie。）

假设一个用户正在浏览一个页面，而该页面包含了一张位于第三方站点上的图像。那么在P3P的环境中，虽然用户所在的页面被认为是安全的，可是第三方站点仍可能存在威胁。 对于CSRF漏洞来讲状况正好相反，虽然第三方站点（是潜在的攻击目标）是安全的，可是用户所在的页面却存在潜在的危害。若是Internet Explorer认为一个第三方站点是危险的，那么它就会阻止向那个站点发送cookes。这样作可以在使用会话cookie的状况下有效地阻止CSRF攻击 ，由于Internet Explorer从跨站请求中提取验证信息。

Internet Explorer的P3P政策对CSRF漏洞的影响很是有趣：具备有效P3P政策的站点没法防范CSRF攻击(Internet Explorer认为这些站点是安全的，而且容许Cookie），而没有该政策的站点却能防护（Internet Explore认为这些站点是危险的，并拦阻Cookie）CSRF攻击。 注意，这些只对使用Cookie进行认证的受CSRF漏洞影响的站点有效。使用其它的类型的认证的站点可能仍然对CSRF攻击有脆弱性。

总而言之，当使用会话cookie进行认证而且目标站点没有实现P3P政策的时候，Internet Explorer使用P3P可以让用户的IE免受CSRF攻击。这项保护措施是P3P政策的无意插柳之做，由于它的本意并不是防止CSRF攻击。因此，站点应该实现咱们的建议的服务器端保护措施，具体如本文下篇所述。

9、小结

本文咱们对跨站请求伪造攻击的原理作了深刻分析，并指出了该漏洞的根本缘由所在；同时介绍了该漏洞的攻击向量，以及它与跨站脚本攻击之间的关系。以后后，说明了现有的安全模型，如同源策略等是没法防护该漏洞的。最后，说明了P3P对于跨站请求伪造的做用。

在下篇中，咱们将向读者介绍在一些大型站点上发现的几个严重的CSRF漏洞，攻击者利用这些漏洞不只可以采集用户的电子邮件地址，侵犯用户隐私并操控用户账户。实际上，若是金融站点出现了跨站请求伪造漏洞的话，这些漏洞甚至容许攻击者从用户的银行账户中划走资金。为了全面的防护CSRF攻击，建议对服务器端进行改造。此外，咱们还会介绍服务器端解决方案应具有的特征，若是缺少这些特性，就会致使CSRF保护措施没必要要地妨碍典型的web浏览活动。除此以外，咱们还将介绍一个客户端浏览器插件，有了该插件的保护，即便站点自身没有保护措施的状况下，用户也能免受某些类型的CSRF攻击的滋扰。跨站请求伪造是一种严重的Web漏洞，但愿你们能提升对CSRF攻击的防范意识。