csrf漏洞防御方案_「网络安全」常见攻击篇（7）——CSRF

CSRF是英语Cross-site request forgery的缩写&＃xff0c;中文意思是“跨站请求伪造”&＃xff0c; 是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。

CSRF与跨站脚本攻击(XSS)相比&＃xff0c;XSS 利用的是用户对指定网站的信任&＃xff0c;CSRF 利用的是网站对用户网页浏览器的信任。

CSRF攻击原理比较简单&＃xff0c;如图所示。其中WebA为存在CSRF漏洞的网站&＃xff0c;WebB为攻击者构建的恶意网站&＃xff0c;UserC为WebA网站的合法用户。

1. 用户C打开浏览器&＃xff0c;访问受信任网站A&＃xff0c;输入用户名和密码请求登录网站A&＃xff1b;
2. 在用户信息通过验证后&＃xff0c;网站A产生COOKIE信息并返回给浏览器&＃xff0c;此时用户登录网站A成功&＃xff0c;可以正常发送请求到网站A&＃xff1b;
3. 用户未退出网站A之前&＃xff0c;在同一浏览器中&＃xff0c;打开一个TAB页访问网站B&＃xff1b;
4. 网站B接收到用户请求后&＃xff0c;返回一些攻击性代码&＃xff0c;并发出一个请求要求访问第三方站点A&＃xff1b;
5. 浏览器在接收到这些攻击性代码后&＃xff0c;根据网站B的请求&＃xff0c;在用户不知情的情况下携带COOKIE信息&＃xff0c;向网站A发出请求。网站A并不知道该请求其实是由B发起的&＃xff0c;所以会根据用户C的COOKIE信息以C的权限处理该请求&＃xff0c;导致来自网站B的恶意代码被执行。

检测CSRF漏洞是一项比较繁琐的工作&＃xff0c;最简单的方法就是抓取一个正常请求的数据包&＃xff0c;去掉Referer字段后再重新提交&＃xff0c;如果该提交还有效&＃xff0c;那么基本上可以确定存在CSRF漏洞。

随着对CSRF漏洞研究的不断深入&＃xff0c;不断涌现出一些专门针对CSRF漏洞进行检测的工具&＃xff0c;如CSRFTester&＃xff0c;CSRF Request Builder等。

以CSRFTester工具为例&＃xff0c;CSRF漏洞检测工具的测试原理如下&＃xff1a;使用CSRFTester进行测试时&＃xff0c;首先需要抓取我们在浏览器中访问过的所有链接以及所有的表单等信息&＃xff0c;然后通过在CSRFTester中修改相应的表单等信息&＃xff0c;重新提交&＃xff0c;这相当于一次伪造客户端请求。如果修改后的测试请求成功被网站服务器接受&＃xff0c;则说明存在CSRF漏洞&＃xff0c;当然此款工具也可以被用来进行CSRF攻击。

• 验证HTTPReferer字段

根据HTTP协议&＃xff0c;在HTTP头中有一个字段叫Referer&＃xff0c;它记录了该HTTP请求的来源地址。在通常情况下&＃xff0c;访问一个安全受限页面的请求必须来自于同一个网站。比如某银行的转账是通过用户访问http://bank.test/test?page&＃61;10&userID&＃61;101&money&＃61;10000页面完成&＃xff0c;用户必须先登录bank.test&＃xff0c;然后通过点击页面上的按钮来触发转账事件。当用户提交请求时&＃xff0c;该转账请求的Referer值就会是转账按钮所在页面的URL(本例中&＃xff0c;通常是以bank.test域名开头的地址)。而如果攻击者要对银行网站实施CSRF攻击&＃xff0c;他只能在自己的网站构造请求&＃xff0c;当用户通过攻击者的网站发送请求到银行时&＃xff0c;该请求的Referer是指向攻击者的网站。因此&＃xff0c;要防御CSRF攻击&＃xff0c;银行网站只需要对于每一个转账请求验证其Referer值&＃xff0c;如果是以bank.test开头的域名&＃xff0c;则说明该请求是来自银行网站自己的请求&＃xff0c;是合法的。如果Referer是其他网站的话&＃xff0c;就有可能是CSRF攻击&＃xff0c;则拒绝该请求。

• 在请求地址中添加token并验证

CSRF攻击之所以能够成功&＃xff0c;是因为攻击者可以伪造用户的请求&＃xff0c;该请求中所有的用户验证信息都存在于COOKIE中&＃xff0c;因此攻击者可以在不知道这些验证信息的情况下直接利用用户自己的COOKIE来通过安全验证。由此可知&＃xff0c;抵御CSRF攻击的关键在于&＃xff1a;在请求中放入攻击者所不能伪造的信息&＃xff0c;并且该信息不存在于COOKIE之中。鉴于此&＃xff0c;系统开发者可以在HTTP请求中以参数的形式加入一个随机产生的token&＃xff0c;并在服务器端建立一个拦截器来验证这个token&＃xff0c;如果请求中没有token或者token内容不正确&＃xff0c;则认为可能是CSRF攻击而拒绝该请求。

• 在HTTP头中自定义属性并验证

自定义属性的方法也是使用token并进行验证&＃xff0c;和前一种方法不同的是&＃xff0c;这里并不是把token以参数的形式置于HTTP请求之中&＃xff0c;而是把它放到HTTP头中自定义的属性里。通过xmlHttpRequest这个类&＃xff0c;可以一次性给所有该类请求加上csrftoken这个HTTP头属性&＃xff0c;并把token值放入其中。这样解决了前一种方法在请求中加入token的不便&＃xff0c;同时&＃xff0c;通过这个类请求的地址不会被记录到浏览器的地址栏&＃xff0c;也也不用担心token会通过Referer泄露到其他网站。

• 其他防御方法

CSRF攻击是有条件的&＃xff0c;当用户访问恶意链接时&＃xff0c;认证的COOKIE仍然有效&＃xff0c;所以当用户关闭页面时要及时清除认证COOKIE&＃xff0c;对支持TAB模式(新标签打开网页)的浏览器尤为重要。2.

尽量少用或不要用request()类变量&＃xff0c;获取参数指定request.form()还是request.querystring()&＃xff0c;这样有利于阻止CSRF漏洞攻击&＃xff0c;此方法只不能完全防御CSRF攻击&＃xff0c;只是一定程度上增加了攻击的难度。

上一篇&＃xff1a;「网络安全」常见攻击篇(6)——木马攻击

下一篇&＃xff1a;「网络安全」常见攻击篇(8)——恶意软件攻击