CSRF(Cross-site Request Forgery),跨站请求伪造。OWASP Top 10 2013、2017都收录了这个漏洞。
原理简单来说就是:
用户登录了某银行站点,浏览信息。
然后被某某广告吸引,点开了另一个站点(恶意站点)。
用户在不知情的情况,点击恶意站点某按钮、链接,如下。
该链接实施转账操作,由于用户登录银行站点的会话有效,在不知情的情况下提交了转账。
http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243
漏洞的特点:
漏洞通过伪造请求,利用用户的会话进行提交操作,漏洞利用难度不算很大,需要一些社工手段。
漏洞危害,主要看业务和场景。
在乌云上看到CSRF相关漏洞,比如微博关注,配合XSS获取管理员后台,配合其他漏洞获取shell、代码执行等。
有个login csrf 比较特别。一般csrf利用用户的会话进行提交,如果都没登录,csrf有啥意义呢?恶意用户可以构造csrf请求,使用攻击者账号、密码,诱骗用户登录后,通过观察用户的行为、搜索等挖掘有意义信息。
针对一些关键操作,构造恶意html进行提交,查看提交结果。
Burp支持csrf poc 生成。示例代码如下:
OWASP 有一个CSRFTester项目,可以做检测,找时间再试下。
CSRF是一个比较奇特的漏洞,防御思路主要还是验证请求来自用户的真实操作。
验证码主要用来做人机区分,用来做CSRF防御算是比较简洁的方法。
攻击者构造恶意请求、页面,用户点击提交,无验证码则拒绝操作,起到防护的效果。
一般支付操作基本都进行了二次验证、多因素验证,比如短信验证码、密码,甚至有些需要U盾。
使用验证码,必然会对用户体验产生影响。另外一方面,不可能全站所有操作都加验证码。
所以,验证码可以作为辅助手段,对于重要操作在平衡易用性和安全的前提下选择使用。
HTTP header中referer字段记录了请求的来源地址。
例如,访问csdn、然后进入博客,请求头中referer如下截图。
当用户点击恶意构造页面提交请求时,验证referer字段是否正常进行CSRF防护。
这种方法比较简单,但是只能作为辅助手段。Referer值来源于浏览器,在部分浏览器可篡改Referer的值;同时,用户可能担心隐私问题,在浏览器设置不发送Referer。
由于攻击者利用了用户Cookie,服务端无法验证是否为用户真实请求。
为了进行验证,增加攻击者不能伪造的信息(token,基于加密、HMAC等),并在服务端进行验证。
token生成需要注意:
使用token,随之也带来这样的问题。
在某些场景,用户可能会开启多个tab页或多个客户端进行操作,如果对于同一个请求维护多个token势必后增加后台复杂度;如果只维护一个token,当该token被消耗以后,其他页面则无法提交。
具体防御的方案还需结合业务实际情况进行处理。
参考:
《白帽子讲web安全》
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md
https://www.cnblogs.com/lovesong/p/5233195.html
https://www.cnblogs.com/wangyuyu/p/3388169.html
https://www.ibm.com/developerworks/cn/web/1102_niugang_csrf/index.html
http://blog.nsfocus.net/fix-summary-csrf/
https://segmentfault.com/a/1190000006672214?utm_source=weekly&utm_medium=email&utm_campaign=email_weekly#articleHeader11
http://www.anquan.us/static/bugs/wooyun-2016-0204481.html
http://www.anquan.us/static/bugs/wooyun-2016-0182693.html
http://www.anquan.us/static/bugs/wooyun-2016-0177823.html
http://www.anquan.us/static/bugs/wooyun-2015-0152241.html
https://www.freebuf.com/articles/web/206407.html