为了账号安全,请及时绑定邮箱和手机立即绑定
首页 手记 http你不得不知道的那些事(二)--CSRF

http你不得不知道的那些事(二)--CSRF

2017.10.13 17:02 4195浏览

之前分享了同源策略,这一篇开始分享web安全的东西。其中也会涉及到一些同源策略的知识,在这一篇中我就不展开讲了,如果有不清楚的,可以去看我之前写的两篇文章,http你不得不知道的那些事(一)--同源策略。以下是本篇文章的内容:

CSRF:CSRF(Cross-site request forgery)跨站请求伪造,也被称为“One Click Attack”或者Session Riding,通常缩写为CSRF或者XSRF,是一种对网站的恶意利用(摘自百度百科)。

跨域请求伪造?跨域?对这个攻击方式必须跨域,如果不跨域就不叫CSRF就叫XSS了(我自己理解的,利用页面内js漏洞进行攻击)。请求伪造?是的,必须发起请求,不发起请求就不能进行伪造。伪造?伪造什么?伪造受信任的用户。举个例子:我是张三,我想炸了李四,但李四和我有仇肯定防着我,此时我就迂回一下,把炸弹包装好,找了个快递公司,让他们帮我把快递送给李四。然后快递员就把我的委托的包裹送给了李四,李四打开包裹一看,王炸!!!

上面这个故事中,我是攻击者,快递员李四信任的用户,是不明真相的受害者,李四是被攻击者。那么web中要如何做到CSRF呢?盗了一张图
图片描述

1.登录受信任网站A,并在本地生成Cookie。

2.在不登出A的情况下,访问危险网站B。

具体描述我就不讲了,大家可以参考这篇文章:
http://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html
讲得比较清楚。

我这里讲讲我自己理解的比较好的防御方式。

1、最简单方便的方法是服务端判断请求头中referer,如果不是当前域的直接就抛弃这个请求。但是比较致命的缺点是,有些浏览器可以直接通过软件修改referer字段值,并且有些组织可能会禁用referer,让服务器获取不到这个字段从而抛弃正常用户请求。

2、增加一个token,用户访问页面时返回用户一个token,以后每次请求都带上这个token作为参数,这个比较保险。缺点是比较繁琐,需要每个请求都加上一个参数。

3、服务器端生成一个随机数,随机数放到cookie中,增加一个表单隐藏域,值为当前随机数。服务器匹配时校验随机数是否一致,由于同源策略的限制,不同源的文档不能相互获取cookie,所以这个方案是可行的。不过这个方案有个缺点是用户如果通过XSS攻击获取了cookie也能进行CSRF攻击,此时我们可以通过在cookie中设置httpOnly属性,不让浏览器端通过脚本获取cookie。反正这个方法就是比较繁琐,不太好用。

4、验证码,这个我就不用多说了,大部分网站登录注册都会使用验证码,验证码不仅可以用来防止猜测密码,还可以防止CSRF攻击。

5、尽量采用post请求,减少CSRF攻击方式。现在大部分能绕过跨域的都是get请求,如src这种偏多,方式也比较多样。这样防御起来范围会相对较少。

以上五点就是我认为比较好的方式,如果大家还有方案,欢迎在留言区留言~thx。

点击查看更多内容
4人点赞

若觉得本文不错,就分享一下吧!

评论

作者其他优质文章

正在加载中
Web前端工程师
手记
粉丝
9113
获赞与收藏
2571

关注TA,一起探索更多经验知识

同主题相似文章浏览排行榜

风间影月说签约讲师

51篇手记,涉及Java、MySQL、Redis、Spring等方向

进入讨论

Tony Bai 说签约讲师

151篇手记,涉及Go、C、Java、Python等方向

进入讨论
感谢您的支持,我会继续努力的~
扫码打赏,你说多少就多少
赞赏金额会直接到老师账户
支付方式
打开微信扫一扫,即可进行扫码打赏哦
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消