谨慎能捕千秋蝉(二)——CSRF

我怕爱的太早我们不能终老 提交于 2020-01-17 16:28:20

CSRF(Cross Site Request Forgery)跨站点请求伪造。

CSRF的本质是当重要操作的参数都能被攻击者预测到,才能成功伪造请求。

一、场景演示

下图是一个伪造请求的场景,按顺序来看;

1、2是正常登陆并产生Cookie,3、4是在登陆后访问骇客的网站并发请求,5是服务器执行骇客发出的请求。

这个场景的关键就是带上Cookie伪造请求。

1)浏览器中的Cookie

浏览器有“Session Cookie”(临时Cookie)和“Third-party Cookie”(本地Cookie);

前者浏览器关闭后就失效了,后者指定了Expire时间,只有超过了时间才会失效。

默认会拦截“Third-party Cookie”的有IE6、IE7、IE8、Safari;

不会拦截的有Firefox、Opera、Chrome等,我就验证了Firefox、Chrome、以及IE8。

2)验证浏览器的支持

设计两个域名“www.normal.net”(正常的网站)和“www.csrf.net”(伪造的网站)

1. 访问“www.normal.net/cookie.php”页面,在cookie.php中设置Cookie,用PHP代码实现。

<?php
    setcookie("cookie1",'session');
    setcookie("cookie2",'third',time()+3600*24);

2. 接着访问“www.csrf.net/csrf.html”,在csrf页面中添加了一个iframe,通过iframe访问normal网站。

<iframe src="http://www.normal.net"></iframe>

3. 查看用iframe访问normal网站中的请求头信息,Cookie只有IE8会拦截,接下来会说明一种绕过拦截的方法。

Firefox

Chrome

IE8

 

3)P3P头

P3P头(Platform for Privacy Preferences Project)隐私偏好项目平台,通过加这个头,可以让IE不拦截第三方Cookie。

不过IE11以及Microsoft Edge将不在支持P3P头。

1. 还是用PHP来实现,与上面的不同之处用加红区分。

<?php
    header("P3P: CP=CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR");
    setcookie("cookie1",'session');
    setcookie("cookie2",'third',time()+3600*24);

2. 请求“www.normal.net/cookie.php”页面,响应头中有下面一句话。

3. 在iframe中访问normal网站的请求头中出现了两个Cookie。

4)GET或POST请求

HTML中能够设置src/href的标签都可以发起一个GET请求,例如上面的攻击通过iframe的src属性发起的。

<link href=""/>
<img src=""/>
<meta http-equiv="refresh" content="0; url="/><!--HTML重定向-->
<script src=""></script>
<a href=""></a>
<video src=""></video>
<audio src=""></audio>
...

攻击者还可以通过伪造表单来执行POST请求,例如在一张页面中布置好输入框、选择框等标签,通过JavaScript自动提交。

 

二、CSRF的危害

1)篡改目标网站上的用户数据

2)盗取用户隐私数据

3)作为其他攻击的辅助手法

4)传播CSRF蠕虫

例如某个社交网站爆出的漏洞,让某个用户查看恶意页面后,给他所有好友发送短信,短信中又包含了这个恶意页面;

好友点击的话,又会给他的好友发送短信,这样就开始了传播,受感染的人也将越来越多。

CSRF蠕虫的原理和XSS蠕虫基本类似,但也略有不同:

1. CSRF的攻击代码存在于攻击者页面中,目标网站传播的内容都包含攻击者页面的URL。还有前提,目标用户登录了目标网站,之后的传播需要带上目标用户的“Session Cookie”。

2. XSS的攻击代码存在于目标页面中,即使是Script从攻击域上引进来的,对JavaScript上下文来说,也属于目标网站。

 

三、CSRF的防御

1)验证码

CSRF的过程,往往是在用户不知情的请求下发起了网络请求;

而加了验证码,就让用户必须与应用进行交互,才能完成最终请求,能够遏制CSRF的攻击。

但是加了验证码后,在用户体验上面会大打折扣,所以要因地制宜。

2)Referer Check

Referer Check常用于“防止图片盗链”,同理,也可以检查请求是否来自合法的“源”。

但Referer Check有缺陷,服务器并非任何时候都能取到Referer,例如HTTPS跳转到HTTP,就不会发送。

3)Anti CSRF Token

在每个请求中增加一个Token参数,这个Token是个随机数,为用户和服务器共同持有,不能被第三者知晓。

Token可放在用户的Session或Cookie中,为了使用方便,还可设置一个生命周期

在提交请求的时候,服务器只需验证表单中的Token和Session(或Cookie)中的Token是否一致即可遏制CSRF攻击。

但在XSS的攻击下,Token会无效,因为XSS可以模拟客户端浏览器执行任意操作,那就可以读取出Token,再构造一个合法的请求,这个过程称为XSRF

4)SameSite属性

SameSite是Cookie的一个属性,可让Cookie在跨站请求时不被传送,从而就能阻止CSRF攻击。它有三个值:

(1)None:浏览器会在同站请求、跨站请求下继续传送Cookie。

(2)Strict:浏览器将只传送相同站点请求的Cookie,即当前网页URL与请求目标URL完全一致。

(3)Lax:默认选项,允许部分跨站请求带Cookie,但Form提交或Ajax请求是不会传送Cookie的。

 

demo代码下载:

http://download.csdn.net/download/loneleaf1/9746890

 

参考资料:

zenphoto csrf 攻陷

用P3P header解决iframe跨域访问cookie[各种语言]

 

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!