一 、什么是CSRF

Cross-Site Request Forgery（CSRF），中文一般译作跨站请求伪造。经常入选owasp漏洞列表Top10，在当前web漏洞排行中，与XSS和SQL注入并列前三。与前两者相比，CSRF相对来说受到的关注要小很多，但是危害却非常大。

通常情况下，有三种方法被广泛用来防御CSRF攻击：验证token，验证HTTP请求的Referer，还有验证XMLHttpRequests里的自定义header。鉴于种种原因，这三种方法都不是那么完美，各有利弊。

 二、 CSRF的分类

在跨站请求伪造（CSRF）攻击里面，攻击者通过用户的浏览器来注入额外的网络请求，来破坏一个网站会话的完整性。而浏览器的安全策略是允许当前页面发送到任何地址的请求，因此也就意味着当用户在浏览他/她无法控制的资源时，攻击者可以控制页面的内容来控制浏览器发送它精心构造的请求。

1、网络连接。例如，如果攻击者无法直接访问防火墙内的资源，他可以利用防火墙内用户的浏览器间接的对他所想访问的资源发送网络请求。甚至还有这样一种情况，攻击者为了绕过基于IP地址的验证策略，利用受害者的IP地址来发起他想发起的请求。

2、获知浏览器的状态。当浏览器发送请求时，通常情况下，网络协议里包含了浏览器的状态。这其中包括很多，比如cookie，客户端证书或基于身份验证的header。因此，当攻击者借助浏览器向需要上述这些cookie，证书和header等作验证的站点发送请求的时候，站点则无法区分真实用户和攻击者。

3、改变浏览器的状态。当攻击者借助浏览器发起一个请求的时候，浏览器也会分析并相应服务端的response。举个例子，如果服务端的response里包含有一个Set-Cookie的header，浏览器会相应这个Set-Cookie，并修改存储在本地的cookie。这些改动都会导致很微妙的攻击，我们将在第三部分描述。

作用范围内的威胁：我们按照产生危害的大小将此部分分成三种不同的危害模型。

1、论坛可交互的地方。很多网站，比如论坛允许用户自定义有限种类的内容。举例来说，通常情况下，网站允许用户提交一些被动的如图像或链接等内容。如果攻击者让图像的url指向一个恶意的地址，那么本次网络请求很有可能导致CSRF攻击。这些地方都可以发起请求，但这些请求不能自定义HTTP header，而且必须使用GET方法。尽管HTTP协议规范要求请求不能带有危害，但是很多网站并不符合这一要求。

2、Web攻击者。在这里web攻击者的定义是指有自己的独立域名的恶意代理，比如attacker.com，并且拥有attacker.com的HTTPS证书和web服务器。所有的这些功能只需要花10美元即可以做到。一旦用户访问attacker.com，攻击者就可以同时用GET和POST方法发起跨站请求，即为CSRF攻击。

3、网络攻击者。这里的网络攻击者指的是能控制用户网络连接的恶意代理。比如，攻击者可以通过控制无线路由器或者DNS服务器来控制用户的网络连接。这种攻击比web攻击需要更多的资源和准备，但我们认为这对HTTPS站点也有威胁。因为HTTPS站点只能防护有源网络。

作用范围外的威胁：下面我们还列出了一些不在本论文讨论范围的相关危害模型。对这些危害的防御措施可以与CSRF的防御措施形成很好的互补。

1、跨站脚本（XSS）。如果攻击者能够向网站注入脚本，那么攻击者就会破坏该网站用户会话的完整性和保密性。有些XSS攻击需要发起网络请求，比如将用户银行账户里的钱转移到攻击者的账户里，但是通常情况下，对CSRF的防御并没有考虑到这些情况。考虑到更安全的做法，网站必须实现对XSS和CSRF的同时防御。

2、恶意软件。如果攻击者能够在用户的电脑上运行恶意软件，那么攻击者就可以控制用户的浏览器向那些可信的网站注入脚本。这时候基于浏览器的防御策略将会失效，因为攻击者可以用含有恶意插件的浏览器来替换用户的浏览器。

3、DNS的重新绑定。像CSRF一样，DNS重新绑定可以使用用户的IP地址来连接攻击者指定的服务器。处在防火墙保护内的服务器或者那些基于IP地址验证的服务器需要一个对抗DNS重新绑定的防御方案。尽管DNS重新绑定的攻击和CSRF攻击的意图非常相似，但是他们还是需要各自不同的解决方案。一个简单的解决DNS重新绑定攻击的方案就是要验证主机的HTTP请求header，确保包含有预期值。还有一个替代方案就是过滤DNS流量，防止将外部的DNS名称解析成内部私有地址。

4、证书错误。如果用户在出现HTTPS证书错误的时候还愿意继续点击访问，那么HTTPS能够提供的很多安全保护就没有意义。有一些安全研究者指出了针对这一种情况的威害，但是在本文中，我们假设用户不会在出现了HTTPS证书错误之后继续点击访问。

5、钓鱼。当用户在访问钓鱼网站的时候，在身份验证的时候输入个人信息，钓鱼攻击就发生了。钓鱼攻击现今非常普遍也很有效，因为用户有的时候真的很难区分钓鱼网站和真正的网站。

6、用户跟踪。一些合作网站会利用跨站请求来对用户的浏览习惯建立一个关联行为库。大多数浏览器都通过组织第三方cookie发送来阻止类似的跟踪，但是利用挂站请求，浏览器的这一特性可以被绕过。

三 、登录CSRF

无论是利用浏览器的网络连接还是利用浏览器的状态，大多数对CSRF的讨论都集中在能改变服务端状态的请求上面。尽管CSRF攻击能通过改变浏览器的状态来对用户在访问可信网站时候造成危害，但是对它的重视程度还是不够。再登陆CSRF攻击里面，攻击者利用用户在可信网站的用户名和密码来对网站发起一个伪造请求。一旦请求成功，服务器端就会响应一个Set-Cookie的header，浏览器接收到以后就会建立一个session cookie，并记录用户的登陆状态。这个session cookie被用作绑定后续的请求，因而也可被攻击者用来作为身份验证。依据不同的网站，登陆CSRF攻击还可以造成很严重的后果。

搜索记录：包括谷歌和雅虎等很多搜索引擎允许他们的用户选择是否同意保存他们的搜索记录，并且为用户提供一个接口来查看他们自己的私人搜索记录。搜索请求里面包含了用户的行为习惯和兴趣的一些敏感细节，攻击者可以利用这些细节来欺骗用户，盗窃用户的身份或者窥探用户。当攻击者以用户身份登陆到搜索引擎里，就可以看到用户的搜索记录。如图1. 这样，用户的搜索查询记录就被存储到了攻击者的搜索记录里，攻击者就可以登陆自己的账户随便查询用户的搜索记录。

图1. 登陆CSRF攻击事件的跟踪图。受害人访问攻击者的网站，攻击者向谷歌伪造一个跨站点请求的登陆框，造成受害者被攻击者登陆到谷歌。随后，受害者使用搜索的时候，搜索记录就被攻击者记录下来。

PayPal：PayPal允许它的用户相互之间任意转移资金。转移资金的时候，用户要注册信用卡或者银行账户。攻击者可以利用登陆CSRF来发起以下攻击：

1、受害者访问了恶意商家的网站，并选择使用PayPal支付。

2、受害者被重定向到PayPal并且要求登陆他/她的账户。

3、网站等待用户登陆他/她的PayPal账户。

4、付款的时候，受害者先是登记自己的信用卡，但是信用卡实际上已经被添加到恶意商家的PayPal账户。

iGoogle：用户可以通过使用iGoogle来定制自己的谷歌主页，也包括一些插件。为了易用性，这些插件是“嵌入到iGoogle的”，这也就意味着他们将影响到iGoogle的安全。通常情况下，iGoogle在添加新插件的时候，都会询问用户做出信任决定。但是攻击者可以通过登录CSRF攻击来帮助用户做出决定，从而安装任意的插件。

1、攻击者通过用户的浏览器授权安装一个iGoogle插件（含有恶意脚本），并将插件添加到用户的定制化iGoogle主页。

2、攻击者使用户登陆谷歌，并开一个到iGoogle的框架。

3、谷歌认为受害者就是攻击者，并将攻击者的插件推送给受害者，而且允许攻击者在https://www.google.com域下运行脚本。

4、攻击者现在可以：（a）在正确的URL页面构造一个登陆框（b）盗取用户自动填充的密码（c）在另一个窗口等待用户登陆并读取document.cookie。

我们已经将上述漏洞告知了谷歌，他们已经在两方面来减缓漏洞带来的危害。首先，谷歌已经弃用内嵌的插件并禁止开发者开发类似的插件，只允许少部分比较受欢迎的内嵌插件。其次，谷歌已经开发了私密token策略来防御登陆CSRF(下面将会讨论)，但是这个策略只对登陆了的用户才有效。我们预计，谷歌一旦充分测试了他们的防御方案并觉得有效之后，会否认他们的登陆CSRF漏洞。

 四 、现有的CSRF防御方案

一般网站有三种防御CSRF攻击的方案。（1）验证token值。（2）验证HTTP头的Referer。（3）用XMLHttpRequest附加在header里。以上三种方法都在广泛使用，但是他们的效果都不是那么的令人满意。

 4.2 Token验证

在每个HTTP请求里附加一部分信息是一个防御CSRF攻击的很好的方法，因为这样可以判断请求是否已经授权。这个“验证token”应该不能轻易的被未登录的用户猜测出来。如果请求里面没有这个验证token或者token不能匹配的话，服务器应该拒绝这个请求。

Token验证的方法可以用来防御登陆CSRF，但是开发者往往会忘记验证，因为如果没有登陆，就不能通过session来绑定CSRF token。网站要想用验证token的方式来防御登陆CSRF攻击的话，就必须先创建一个“前session”，这样才能部署CSRF的防御方案，在验证通过了之后，再创建一个真正的session。

Token的设计。有很多技术可以生成验证token。

• session标识符。浏览器的cookie存储方式就是为了防止不同域之间互相访问cookie。一个普遍的做法是直接利用用户的session标识符来作为验证token。服务器在处理每一个请求时，都将用户的token与session标识符来匹配。如果攻击者能够猜测出用户的token，那么他就能登录用户的账户。而且这样做有个不好的地方在于，偶尔用户正在浏览的内容会发送给第三方，比如通过电子邮件直接上网页内容上传到浏览器厂商的bug跟踪数据库。如果正好这个页面包含有用户的session标识符，任何能看到这个页面的人都能模拟用户登陆到网站，直到会话过期。

• 独立session随机数。与直接使用用户的session标识符不一样的是，当用户第一次登陆网站的时候，服务器可以产生一个随机数并将它存储在用户的cookie里面。对于每一个请求，服务器都会将token与存储在cookie里的值匹配。例如，广泛使用的Trac问题跟踪系统就是用的此技术。但是这个方法不能防御主动的网络攻击，即使是整个web应用都使用的是HTTPS协议。因为攻击者可以使用他自己的CSRF token来覆盖来覆盖这个独立session随机数，进而可以使用一个匹配的token来伪造一个跨站请求。

• 依赖session随机数。有一个改进产生随机数的方法是将用户的session标识符与CSRF token建立对应关系后存储在服务端。服务器在处理请求的时候，验证请求中的token是否与session标识符匹配。这个方法有个不好的地方就是服务端必须要维护一个很大的对应关系表（哈希表）。

• session标识符的HMAC。有一种方法不需要服务端来维护哈希表，就是可以对用户的session token做一个加密后用作CSRF 的token。例如， Ruby on Rails的web程序一般都是使用的这种方法，而且他们是使用session标识符的HMAC来作为CSRF token的。只要所有的网站服务器都共享了HMAC密钥，那么每个服务器都可以验证请求里的CSRF token 是否与session标识符匹配。HMAC的特性能确保即使攻击者知道用户的CSRF token，也不能推断出用户的session标识符。

鉴于有充足的资源，网站都可以使用HMAC方法来防御CSRF攻击。但是，很多网站和一些CSRF的防御框架（比如NoForge, CSRFx 和CSRFGuard）都不能正确的实现比较隐秘的token防御。一个常见的错误就是在处理跨站请求的时候暴露了CSRF token。举个例子，一个可信的网站在对另一个网站发起请求的时候附加上了CSRF token，那么那个网站就可以对这个可信的网站伪造一个跨站请求。

案例研究：NoForge.NoForge就是使用服务端保存哈希表的方式来验证用户的CSRF token。它在所有链接和表单提交的时候会附加一个CSRF token，造成这种技术不太完善的原因有以下三个：

1、HTML是在浏览器里动态创建的，而不会被重新加上CSRF token。有些网站是在客户端创建HTML的。比如Gmail, Flickr, 和 Digg都是用JavaScript 来创建表单，而这些表单正是需要CSRF防御措施的。

2、NoForge并没有对指向本站和外站的超链接作区分。如果有一个指向外站的超链接，那么外站可以用请求里面获取到用户的CSRF token。比如，如果phpBB部署了NoForge，那么一旦用户点击了一个连接，连接的站点就可以获取到用户的CSRF token，即使NoForge区分了是本站的链接还是外站的链接，因为Referer 还是会暴露用户的CSRF token。

3、NoForge对登陆CSRF并没有什么效果，因为如果用户已经有了session标识符（登陆了），那么NoForge只会验证CSRF token。尽管这种缺陷是可以修复，但是这也说明了要想正确的实施token验证策略并不是一件很容易的事情。

虽然上述三个原因都是可以修复的，但是这些缺陷都说明了要想正确地实施token验证策略，是很复杂的一件事情。CSRFx 和 CSRFGuard，还有很多网站都说明了这一问题。

 4.2 Referer

大多数情况下，当浏览器发起一个HTTP请求，其中的Referer标识了请求是从哪里发起的。如果HTTP头里包含有Referer的时候，我们可以区分请求是同域下还是跨站发起的，因为Referer离标明了发起请求的URL。网站也可以通过判断有问题的请求是否是同域下发起的来防御CSRF攻击。

不幸的是，通常Referer会包含有一些敏感信息，可能会侵犯用户的隐私。比如，Referer可以显示用户对某个私密网站的搜索和查询。尽管这些内容对私密网站站长来说是好事，因为他们可以通过这些内容来优化搜索引擎排名，但是一些用户还是认为侵犯了他们的隐私。另外，许多组织也很担忧Referer可能会将内网的一些机密信息泄露出去。

漏洞。从历史上来看，浏览器的一些漏洞使得一些恶意网站有欺骗Referer的价值，尤其是在使用代理服务器的时候。很多对Referer欺骗的讨论都标明浏览器允许Referer可以伪造。Mozilla在Fire-fox 1.0.7里面已经修复了Referer欺骗的漏洞。目前的IE则还有这方面的漏洞，但是这些漏洞只能影响XMLHttpRequest，并且只能用来伪造Referer跳转到攻击者自己的网站。

尺度。如果网站选择使用Referer来防御CSRF攻击的话，那么网站的开发人员就需要决定到底是使用比较宽松还是比较严格的Referer验证策略。如果采用宽松的Referer验证策略，网站就应该阻止Referer值不对的请求。如果请求里面没有Referer，就接收请求。尽管这个方法用的很普遍，但是它很容易被绕过。因为攻击者可以在header里面去掉Referer。例如，FTP和数据URL发起的请求里面就不包含Referer。如果使用严格的Referer验证策略，网站还要阻止没有Referer的请求。这样做主要是为了防止恶意网站主动隐藏Referer，但也会带来兼容性问题，比如会误杀一部分合法的请求，因为有些浏览器和网络的设置默认就是不含有Referer的。所以说这个度一定要掌握好，很多时候取决于经验。我们还会在4.2.1里讨论这个问题。

个案研究：Facebook。纵观Facebook的大部分网站都是使用token认证的方式来防御CSRF攻击的。但是，在Facebook的登陆框部分则使用的是宽松的Referer验证策略。这种方法在面对登陆CSRF的攻击时没有什么作用。举例来说，攻击者可以讲用户从http://attacker.com/重定向到ftp://attacker.com/index.html ，然后再对Facebook发起一个跨站的登陆请求。因为请求来自FTP URL，所以大多数浏览器都不会在请求里包含Referer。

4.2.1 实验

为了评估严格的Referer验证策略的兼容性，我们进行了一项实验来衡量到底有多大概率以及在什么情况下，合法的请求里面不含有Referer。

设计。广告是一个很方便测量浏览器和网络特征的渠道，因此我们可以利用广告作为实验平台。在2008年4月5日到4月8日期间，我们从163,767个独立IP购买了283,945 个广告，分别是两个不同的广告渠道。在渠道A，我们以每千次展示0.50美元的价格购买了网络旗帜广告，关键字为“火狐”，“游戏”，“IE”，“视频”，“YouTube”。在渠道B，我们以每千次展示5美元的价格的间隙广告，关键字为“芭蕾”，“金融“，“花”，“食品”和“园艺”。我们在每个广告渠道上花了100美元，渠道A有241,483点击量（146,310个独立IP），渠道B有42,406点击量（18,314个独立IP）。

广告服务是由我们实验室里的两台主机提供，两个独立的域名是从不同的注册商处购买。每当显示广告时，广告会在接下来的每个请求里面生成一个特定的标识符，并随机选择一台主机作为主服务器。主服务器通过HTTP或者HTTPS协议将客户端HTML发送到我们的服务器，这些HTML能发起一个GET或者POST请求。其中，请求包括提交表单，图像请求和XMLHttpRequests。请求的顺序是随机的并且跟用户的操作无关。当广告通过了浏览器的安全策略之后，就向主服务器发起一个同域的请求，同时向次服务器发起一个跨域请求。每个服务器的成本是400美元，域名是7美元，从一个合法的证书颁发机构获得的90天域验证的HTTPS证书是免费的。服务器根据接收到的网络请求来记录请求参数，包括Referer，User-Agent头，日期，客户端的C类网络，会话标识符。服务器还通过DOM API记录了document.referrer的值，但是不记录客户端的IP地址。为了统计独立的IP地址，服务器利用一个随机产生的KEY而不是记录HMAC的方式，这个KEY会被丢弃。服务器记录的信息不足以单独确定广告的浏览者到底有多少。

伦理。实验的设计遵守两个广告渠道的规则。实验中的行为基本上都是web广告每天的行为，所以都能正常的从广告商那里请求额外的资源，比如图片，音频和视频。尽管我们的广告产生的HTTP请求数目远大于普通的广告，但是我们需要的带宽明显比一个视频广告需要的带宽要小。我们的服务器也像广告商一样，只记录他们所记录的信息。实际上我们的服务器记录的信息明显要比商业的广告商要少，因为我们并不记录客户端的IP地址。

结果。我们已经将结果在图2和图3里总结出来了，我们还发现以下结果只有95%的可信度。

• HTTP方法里， 跨域请求比同域请求不包含Referer头的情况更普遍，而在POST方法(卡方系数= 2130, p值