作为一个开发者并在web架构为主流的时代,多多少少听过看过不少网站攻击事件,比如某网站数据遭黑客攻击造成数据泄露等等,这些事件的发生往往都是因我们开发者某些疏忽或者测试不严谨而留下的漏洞,让某些人有了可乘之机。
文本主要了解一下在web端常见的一种漏洞:CSRF
什么是CSRF ?
CSRF (Cross-site request forger) 的全称是“跨站请求伪造”,属于跨站攻击——不攻击服务器端而攻击正常访问网站的用户，但它们的攻击类型是不同维度上的分 类。CSRF 顾名思义，是伪造请求，冒充用户在站内的正常操作。我们知道，绝大多数网站是通过 cookie 等方式辨识用户身份（包括使用服务器端 Session 的网站，因为 Session ID 也是大多保存在 cookie 里面的），再予以授权的。所以要伪造用户的正常操作，最好的方法是通过 XSS 或链接欺骗等途径，让用户在本机（即拥有身份 cookie 的浏览器端）发起用户所不知道的请求。
CSRF原理
用户A访问B网站,输入账号密码登录成功后在该网站产生了Cookie信息返回给了浏览器,然后用户在未退出该B网站之前或者Cookie未过期之前访问了某危险网站,危险网站中执行了某恶意代码发出访问B网站请求,那么该请求就会附带的登录者Cookie信息以登陆者的身份进行操作,B网站并不知道该请求该危险网站所发起的。
CSRF实例场景
比如在某银行网站,有这么一个转账接口,小明转账1000元给小龙
http://www.bank.com/transfer?toUser=xiaolong&money=1000这个请求发起后,正常的流程服务器首先先会验证该请求session是否合法,并验证该用户是否已登录已通过安全认证,然后对xiaolong用户检测是否存在等等再确定转账操作。
然而攻击者也有该银行账户,学习了CSRF漏洞之后决定攻击小明,将小明账户的钱全部转到自己账户中,如果按照上面接口操作直接将转账人改为自己可不可行呢,结果是不行的,因为攻击者当前并没有登录小明的账号,浏览器中Cookie也没有存储小明账号的信息,所以这样是行不通的,于是攻击者自己写了一个网站,网站中为下列HTML代码
<img src="www.bank.com/transfer?toUser=heike&money=1000" />通过邮件、广告引诱等等一些方式让小明点击了该危险网站,那么该危险网站就会向该地址发起请求,大多数情况下对小明是没有破坏的,但是万一小明刚刚才访问了银行网站,并且还未退出登录或者浏览器中的Cookie信息还未过期,那么该危险网站所发起的转账请求会附带上该Cookie信息以小明的身份发送转账1000元给攻击者账户,服务器并不知道该请求是从危险网站所发过来的,并且Cookie信息正常所以这比转账成功了,这样小明账户就不知不觉少了1000元。
CSRF如何防御
1.通过验证HTTP Referer字段信息是否合法,判断该请求来源是否为本站,(缺点:在版本比较低的浏览器中,Referer可以被伪造)
2.在请求地址中添加token并且进行验证,该攻击手段之所以能够成功,根本原因是因为攻击者能伪造请求并能拿到Cokkie中的登录信息,要解决问题在请求中就不能放入攻击者可以伪造的信息并且这些信息不能存与Cookie中,可以通过HTTP请求以参数的形式传入随机产生的token，在后端设置拦截器对请求中的token进行验证,如果请求参数中没有token或者不正确则认为是恶意攻击则拒绝该请求.(缺点:前端所有请求都得加上token,不能保证token本身安全)
3.将token加入在HTTP请求头自定义属性中,这种方式跟上种基本一致,只是把token参数通过请求头的自定义属性存储传输到后端进行验证(缺点:有局限性, 只能在ajax异步请求使用)
