CSRF

本文来自于对以下两篇文章的整合。
CSRF漏洞详细说明
CSRF攻击的原理及防范科普

1、前景知识

Cross-Site Request Forgery（CSRF），攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以你的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等。

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

CSRF攻击过程的特点：

• 目标用户已经登录了网站，能够执行网站的功能；
• 目标用户访问了攻击者构造的URL。

例如：一个钓鱼网站，界面操作和真是的页面一模一样，当用户操作转账功能的时候，转账数据也会发送到真实的后台，但是其中用户输入的信息中对端账户可能会被修改掉，导致用户确实转账了，但是钱却转给了别人。

2、攻击示意图

下列图片来自于：
https://blog.csdn.net/qq_41606973/article/details/86504747

• 客户端访问服务器时没有同服务器做安全验证
  

3、攻击原理

此部分原文链接：http://www.91ri.org/2983.html

网站是通过隐式认证认证用户时，只要不关闭浏览器或者退出，以后访问相同网站时，浏览器会自动在请求中附带上认证信息。如果浏览器被其它网页控制请求了这个网站的URL，可能会执行一些用户不希望的功能。

下面用例子来说明：

假设某个网站（example．com）保存了用户的电子邮件地址信息．并且通过这个邮箱地址实现密码恢复等功能。网站仅采用了Cookie的隐式认证方式来验证用户．用户在验证登录后可以用如下这个URL来更改自己的邮件地址设置：http://www.91ri.org /setemail=邮件地址

那么攻击者只要创建一个HTML页面包含以下代码：

< IMG src=“ http://www.91ri.org /setemail = 新邮件地址”>

当已经登录过example．com的用户访问这个页面的时候，浏览器就会向example．com发出请求改变用户的邮箱地址。

对于所有使用隐式的认证方式并且没有采取针对CSRF攻击的自我保护措施的网站，几乎都可能存在CSRF漏洞。

4、分类

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

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

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

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

5、危害类型

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

• 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站点只能防护有源网络。

6、CSRF与XSS比较

此部分原文链接：http://www.91ri.org/2983.html

Cross—Site Scripting Cxssl允许攻击者将恶意代码注入到受害网站的网页上，其他使用者在观看网页时就会受到影响。这类攻击通常包含了HTML以及客户端脚本语言。

CSRF与之相比区别在于：XSS攻击需要借助脚本语言，CSRF攻击则未必需要脚本语言：XSS需要受害站点接受用户输人来保存恶意代码。而CSRF攻击可能从第三方网站发起；XSS产生的主要原因是对用户输入没有正确过滤．CSRF产生的主要原因是采用了隐式的认证方式。如果一个网站存在XSS漏洞。那么它很大可能也存在CSRF漏洞。即使一个网站能够完美地坊御XsS漏洞，却未必能够防御CSRF。

另外，CSRF与XSS也不是截然分开的，一个攻击可能既是CSRF攻击。又是XSS攻击。

7、 防范CSRF攻击

此部分原文链接：http://www.91ri.org/2983.html

为了防范CSRF攻击，理论上可以要求对每个发送至该站点的请求都要显式的认证来消除威胁。比如重新输入用户名和口令。但实际上这会导致严重的易用性问题。所以，提出的防范措施既要易于实行，又不能改变现有的Web程序模式和用户习惯，不能显著降低用户体验。

7.1、服务器端的防范措施

(1)对于网站所有接受用户输入的内容进行严格的过滤。这条措施不止针对CSRF漏洞，而主要是减少XSS漏洞的可能性。而一个有XSS漏洞的网站，很难保证它对CSRF是安全的。这条措施是其它安全措施的基础。

(2)GET方法只用于从服务器端读取数据，POST方法用于向服务器端提交或者修改数据。仅使用POST方法提交和修改数据不能防范CSRF攻击，但是会增加攻击的难度。避免攻击者简单地使用< IMG >等标签就能通过GET方法进行CSRF攻击。

同时，这样做也符合RFC2616推荐的Web规范。

(3)在所有POST方法提交的数据中提供一个不可预测的参数，比如一个随机数。或者一个根据时间计算的HASH值。并且在Cookie中也同样保存这个参数。把这个参数嵌入标签保存在FORM表单中，当浏览器提交POST请求到服务器端时．从POST数据中取出这个参数并且和Cook．ie中的值做比较，如果两个值相等则认为请求有效，不相等则拒绝。根据同源策略和Cookie的安全策略，第三方网页是无法取得Cookie中的参数值的．所以它不能构造出相同随机参数的POST请求。

另外，为了保证一个用户同时打开多个表单页面。所有页面都能正常工作，在一次会话的有效期内。只使用同一个随机参数。也就是说，在会话初始化的时候生成一个随机参数，在以后的页面和Cookie中，都使用这个参数。直到会话结束，新的会话开始时，才生成新的参数，否则会只有用户最后一次打开的页面才能正常提交POST请求．多标签或多窗口浏览器会不能正常工作。

(4)在关键的服务器端远程调用动作之前，增加人机交互环节。例如CAPTCHA人机区分识别程序㈣(典型应用如图片验证码)。

(5)利用Cookie安全策略中的安全属性，但是不要完全依赖Cookie安全策略中的安全属性，只信任同源策略，并围绕同源策略来打造Web应用程序的安全性。

(6)正确配置网站针对Flash的跨域策略文件。严格限制跨域、跨站的请求。

7.2、客户端的防范措施

(1)保持浏览器更新，尤其是安全补丁，包括浏览器的Flash插件等的更新。同时也要留意操作系统、杀毒、防火墙等软件的更新。

(2)访问敏感网站(比如信用卡、网上银行等)后，主动清理历史记录、cookie记录、表单记录、密码记录，并重启浏览器才访问其他网站。不要在访问敏感网站的同时上其它网站。

(3)推荐使用某些带有“隐私浏览”功能的浏览器，比如Safail。“隐私浏览”功能可以让用户在上网时不会留下任何痕迹。浏览器不会存储Cookie和其它任何资料．从而CSRF也拿不到有用的信息。IE 8把它叫做“InPfivate浏览”，Chrome称作“Incognito模式”。