不觉间来到新公司已经两个月了,凭借在下的勤劳努力厚脸皮终于在新公司拿到了劳动合同,在下欣喜若狂间不禁想要写一篇短文来纪念一下。😂
介于在下的细心、正直、身材好,我被分到了公司的支付中心做前端,负责全公司的支付业务。既然是涉及到钱的东西,那就不是像以前随便写写业务,封装个对象,弄个抽象类就完事了的。
上一篇把XSS攻击仔细介绍了一下,今天让我们来细聊一下CSRF是怎么搞的吧。
CSRF全名唤做Cross Site Request Forgery,中文名叫跨站点请求伪造。其本质是在用户已经登录的前提下,引诱用户点击钓鱼网站地址,由于用户已经获取到了正规网站的cookie,所以在请求正规网站的时候就可以跳过其对cookie的限制。
——高级装逼工程师 Yubble
情景再现:
下面我们来简单的撸一下这个场景,比如我现在有一个正规的退款功能页面,他可以长这个样子:
这个UI很简约的页面就是我们登录进来的主页面,它的cookie中包含用户的token...
此时间我如果是一个好流弊的黑客,我通过我臭不要脸的手段在页面里塞入一段链接来诱导用户进入我的钓鱼网站。比方说我塞入了这样一条连接。
恰巧受害者又是一位ikun,她不顾一切狠狠地点了进去,结果跳进了我事先写好的陷阱页面里~各位请看:
呐,现在这位小迷妹已经进入了我的钓鱼网站,她现在只要点击任意一个转账的请求就会带上刚刚登陆的正规网站的cookie触发退款了。
原理解答:
看到这里的客爷一定已经憋了一大堆问题想要质问在下,哈哈,反正你也打不到我.....客爷留步,都看到这了再往下看下去吧~
我们知道两个不同域名的网站是无法共享cookie的,且我的点击退款按钮发送的请求也是需要后端来验证cookie中包含的token值的,如下:
问题1:那么用户是如何在访问我的testyubble.com域名的时候将proyubble.com域名下的token带上的呢?
答案就在于,我在钓鱼网站点击“点我给之前的正规网站发个请求(转账)(get)”按钮的时候给html插入了一条iframe:
我们大家都知道jsonp之所以可以发送跨域请求就是因为src这个属性不受同源策略的影响,所以我在钓鱼网站页面插入了iframe标签,它就用get的方式访问了这个http://proyubble.com/returnMoney这个接口。但是!为什么我可以携带上proyubble.com的cookie呢,因为当我登录proyubble.com这个路径的时候,cookie就已经种到我浏览器中了,虽然在testyubble.com这个域名下看不到,但是如果页面中存在包含proyubble.com域名的iframe中的话,cookie是会被浏览器自动带上的。
发送了iframe的请求后,Cookies就存在了两个域名下的内容,查看proyubble.com这个域名的时候,可以看到早已存在浏览器中的cookie被展示出来了。
所以,如果要完成csrf攻击,首先要保证被攻击者是在已经登录被攻击网站的前提下。
问题2:src里放的链接只能按get方法访问,是不是使用Post提交方式就安全了呢?
并不是,post接口也同样可以被跨站点请求,只不过要比get接口复杂一点,客爷请看:
原理上也是借助了iframe中src不受同源策略的影响,在一个form中将提交方式设定为POST,注意target一定要写成iframe的name,这样提交POST请求后会在同一页面中的iframe里显示,不会进行页面跳转也不会打开新的页面。相当于打开了一个域名为proyubble.com的新的窗口,在这个窗口下做了一次对proyubble.com/returnPost的POST请求,就这么简单的又把老实的proyubble.com网站攻破了。
问题3:不法人士是怎么拿到cookie的?
这是昨天团队中一个伙伴问到我的,其实我从头到尾都没有拿到过用户的cookie,因为我用iframe把正规页面嵌进来,所以除非我能在正规网站植入一个postMessage,不然我是无法跨域iframe传递信息的。
简而言之,黑客是在拿不到用户cookie的情况下,对用户行为操作,攻击了正规网站。
如何预防:
方法一:sameSite
在cookie中设置sameSite属性,google主导贡献了这个方案,是专门用来预防sameSite攻击的。它的作用就是限制cookie在不同域名下跟随http请求一起提交。
方法二:Referrer Check
这其实是sameSite出现之前的一个老式方案,它的实现在于每次客户端向服务器发送请求的时候,服务器可以在http头中接收到referrer信息,来确保这个请求是否是安全域名中发送过来的。
方法三:Anti CSRF Token
使用token这种方式还是比较有效的,而且需要将token塞入http的请求头中作为一个特别的字段传输,这么做可以防止CSRF攻击的原因有两点:第一,黑客拿不到,现在就算我将token塞入cookie中,黑客用iframe的方式诱导用户打开钓鱼网站,中间也隔了一层iframe,如果黑客想要跨域拿到cookie中的token除非他能在正规网站中使用postMessage。第二,黑客无法将token塞入http请求头中,就算这个黑客小哥手段高明,真的拿到了cookie中的token,他也是无法在form的POST方法提交的时候增加一个http属性的。
方法四:加验证码
在下愚见,这种操作会增加用户的抵制情绪,慎用!
一直想要说把安全性的CSRF这块儿补上,但是一直也没腾出功夫来,今天把这块儿学完了也算给自己一个交代。前段时间我们的支付中心迸发了一次安全问题,是一个url的漏洞,当然要说web安全最常见的还是xss和csrf这两个。今年的5月份好热,经过了一年多的恋爱在下终于和媳妇领证了,在我的精心呵护下,已经将她从一只小可爱喂成了小肉胖,废话就到这,各位客爷咱们下次见啦~