欢迎来到 黑吧安全网 聚焦网络安全前沿资讯,精华内容,交流技术心得!

Cookie-Form型CSRF防御机制的不足与反思

来源:本站整理 作者:ph17h0n 时间:2016-09-28 TAG: 我要投稿

0x01 借助Session防御CSRF漏洞
我最早接触Web安全的时候(大概大一暑假),写过一个站点。当时边看道哥的《白帽子讲Web安全》,边在写站点的过程中熟悉每种漏洞,并编写尽量安全的代码。
初识CSRF漏洞的我使用了一种中规中矩的方法来防御CSRF漏洞:
1、后端生成随机字符串Token,储存在SESSION中。
2、每当有表单时,从SESSION中取出Token,写入一个隐藏框中,放在表单最底部。
3、接受POST数据时,先验证$_POST['token'] === $_SESSION['token'],再执行其他逻辑。
这是一个很标准的CSRF防御方法,也很难找出其破绽。但这个方法有个致命的弱点:Session。
原因:
1、所有用户,不论是否会提交表单,不论是否会用到这些功能,都将生成一个Session,这将是很大的资源浪费。举个例子,Sec-News的Session储存在redis里,每天会生成数千到数万的Session,自动化脚本每天夜里会遍历并清理没有使用的Session,以避免过度消耗资源。
2、除了PHP的很多开发语言中,Session是可选项,很多网站根本没有Server Session。开发框架不能强迫开发者使用Session,所以在设计防御机制的时候也不会使用Session。
所以,像Django之类的Python框架,会选择基于Cookie的CSRF防御方式。
0x02 Cookie-Form型CSRF防御机制
顾名思义,Cookie-Form型CSRF防御机制,是和Cookie和Form有关。它确切的名字我还不太清楚,暂且这样称之。
Sec-News曾经分享过一篇文章 《前后端分离架构下的CSRF防御机制》,当时 @neargle 就提出过疑问。

其实借助Cookie来防御CSRF的方法是一个通用的防御方法,单纯应对CSRF漏洞是绝对可行的。该文章的解决方案是,后端生成一个token和一个散列,均储存于Cookie中,在提交表单时将token附带在表单中提交给后端,后端即可根据表单中的token和cookie中的散列来验证是否存在CSRF攻击。
实际上散列这一步是没有必要的,后端只需要生成好一个随机token储存于Cookie中,前端提交表单时提交该Cookie基本就万无一失了。
我第一次接触这种防御方法是在学习CodeIgniter的过程中(这里提一下,CI框架默认的CSRF防御方法就是本文说的这个方法),当时认为这种防御方法很不可理喻。因为Cookie是可以控制的,如果攻击者将Cookie控制地和Form中相同,不就可以绕过这个防御了么?
但是细想来,立马打脸了:攻击者如何修改受害者的Cookie?
既然是CSRF漏洞,也就不能控制目标域的脚本,当然就无法获取Cookie(如果能获取Cookie就不叫CSRF漏洞了)。
总结一下,基于Cookie的CSRF防御方法,较基于Session的方法有如下优点:
1、无需使用Session,适用面更广,适合“Secure By Default“原则。
2、Session储存于客户端中,不会给服务器带来压力。
3、没有其他漏洞的情况下,黑客无法接触Cookie,所以保证了Token的机密性,也就可以防御CSRF漏洞。
0x03 破解Cookie-Form型CSRF防御
那么,基于Cookie的CSRF防御机制,有什么弊端?
弊端也很明显,即一旦有其他漏洞(即使是看起来很鸡肋的漏洞)的存在,很容易就能破坏这种防御手法。
我曾经分享过知乎的一个漏洞《知乎某处XSS+刷粉超详细漏洞技术分析》,很经典的一个案例。攻击者获得了一个”看似十分鸡肋“的XSS漏洞(domain是子域名,而且关键cookie都有httponly),无法做一些正常XSS漏洞可以做的攻击,但却可以写入Cookie。
攻击者通过写入一个新的"CSRF_TOKEN",将原有的无法获取的Token覆盖掉,就成功绕过了0x02中描述的防御手法。
这种绕过方法的核心就是:利用其它漏洞写入Cookie,覆盖原有Cookie,来达到Form[token]===Cookie[token]的目的。
那么,寻找此类绕过漏洞的核心就是寻找注入新Cookie的方法,看过一些案例,我归纳出来几种:
1、某些单纯而不做作的前端编写的页面可以写入Cookie
2、鸡肋XSS漏洞
3、利用CRLF漏洞注入Cookie
4、利用畸形字符使后端解析Cookie出错,注入Cookie
第一种,很久以前我在QQ空间的不止一处看到过,某些页面从location.search中获取参数并设置为Cookie。但找这种地方比较难,没有什么特别的方法,可遇而不可求。
第二种,就看知乎那个案例吧。
第三种,@/fd 曾用一个Twitter的overflow漏洞演示了Cookie的注入:《Overflow Trilogy》。这个漏洞原本是可以用来绕过Twitter的CSRF检测的,不过后来Twitter把CSRF防御方式从0x02换成0x01了,有点可惜:

第四种,就是利用Google Analytics来绕过Django的CSRF防御方式。这个方法其实作者早在 2015年 就已经提出来了(当时是作为Twitter的一个漏洞提交的)。
0x04 Web Server解析Cookie的特性
Google Analytics会将网站的path写入Cookie中,而没有进行编码,导致攻击者可以输入一些“特殊”的字符。
当时使用的是逗号“,”,有些Web Server在解析Cookie时,逗号也会成为分隔符。这样就导致了Cookie: param1=1111,param2=2222;这样的Cookie被解析成Cookie[param1]=1111和Cookie[param2]=2222,成功注入了一个新Cookie,Param2 。
这次Django的Cookie注入也类似。其实原因来自于Python原生的cookielib库,在分割Cookie头的时候,将“]”也作为了分隔符,导致Cookie: param1=value1]param2=value2被解析成Cookie[param1]=value1和Cookie[param2]=value2,成功注入了一个新Cookie,Param2。
关于畸形Cookie注入的一些姿势,可以看看 https://habrahabr.ru/post/272187/ 。
成功注入Cookie后,后续“CSRF攻击”流程就和0x03中讲的一样了,不再赘述。思路很不错,所以写文章说说,和大家分享一下自己的一些看法。

【声明】:黑吧安全网(http://www.myhack58.com)登载此文出于传递更多信息之目的,并不代表本站赞同其观点和对其真实性负责,仅适于网络安全技术爱好者学习研究使用,学习中请遵循国家相关法律法规。如有问题请联系我们,联系邮箱admin@myhack58.com,我们会在最短的时间内进行处理。
  • 最新更新
    • 相关阅读
      • 本类热门
        • 最近下载