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漏洞。

 学习路线

对于从来没有接触过网络安全的同学，我们帮你准备了详细的学习成长路线图。可以说是最科学最系统的学习路线，大家跟着这个大的方向学习准没问题。

同时每个成长路线对应的板块都有配套的视频提供：