浅析CSRF

Posted 2021-04-25 胡说or八道

CSRF：跨站脚本攻击(Cross-site Request Forgery),即攻击者盗用网站正常用户的身份,以用户的身份发出恶意请求

过程:一个网站存在转账功能,通过对网站发送请求https://www.xxx.com/pay.php?money=1000&to=your

即可将me用户的1000元钱转账给your用户，这时如果网站不存在防御手段的话,恶意用户就可以重构该请求

https://www.xxx.com/pay.php?money=1000&to=恶意用户

在自己的网站上加入类似于

<img text-align: left;">https://www.xxx.com/pay.php?money=1000&to=恶意用户">的恶意代码  

通过广告,优惠活动等吸引人的事件来诱惑网站用户访问他的网站

当用户访问恶意用户网站并且其在www.xxx.com网站处于登录状态,这个请求就会被执行

简单来说CSRF攻击的成功需要两个条件:

    1.用户访问www.xxx.com时没有退出

    2.同时访问了恶意站点www.danger.com

种类及其简单利用:

CSRF分为两种: GET型CSRF、POST型CSRF

    GET型CSRF: 

<img src='https://www.xxx.com/pay.php?money=1000&to=恶意用户'>

    POST型CSRF:通常利用一个自动提交的表单

<form action="地址" method=POST>      <input type="hidden" name="nam1" value="value1" /></form><script> document.forms[0].submit(); </script>

防御方式:

    一般来说目前主流防御手段为以下三种

    (1)验证referer

        可以通过验证referer来分辨是否为正常用户发出的请求

    (2)添加token

        CSRF成功的关键就是浏览器无法分辨出请求是否由用户'本身'发出，我们可以在HTTP请求中以参数形式加入一个随机产生的token,通过校验每次请求携带的token是否与用户本身的Token相同,来判断是否为CSRF攻击

        虽然理论上token可以防御CSRF攻击,但实际过程中还是存在许多的问题

比如token并未与用户绑定,token可预测等等问题

    (3)增加二次验证

        比如增加验证码等等,虽然安全,但是为了用户体验、不影响网站正常业务不可能在系统的每一个功能点上都如此添加

总结:

1. 防御并不是一成不变,按部就班,需要根据场景以及业务变化而变化

2. 业务与防御需要找到一个平衡点,防御手段不能过多影响网站的正常业务与用户体验,业务又不能过分的减弱防御

3. 不安全的防御方式仍然抵御不了恶意用户的攻击

如下即是一个使用referer进行防御  但校验不严格造成防御形同虚设的案例

以下网站 用 www.xxx.com代替 我们以退出登录处为例  

这里是一个退出登录处的数据包

我们首先按照正常流程不做改变 走一次  结果是退出登录成功

我们删除掉数据包中referer 查看返回包  可以看到  退出登录失败

此时我们可以推断网站存在referer防御

但是网站如何验证的referer还需要测试

之后我们分别尝试

   1.将referer修改为   referer: xxxxxx                 失败

   2.将referer修改为   referer: https://www.baidu.com             失败

   3.将referer修改为   referer: https://www.xxx.com/qqqqqq        成功

   4.将referer修改为   referer: xxx.com          成功

通过这几次尝试  可以得知网站只验证referer中是否存在  xxx.com

所以我们只需要伪造的referer包含xxx.com即可绕过防御

这里存在两种绕过方法

其一:我们在服务器目录下创建一个目录名叫 xxx.com

其二:我们创建一个html文件  名叫 xxx.com.html

即可绕过防御