借刀杀人。

跨站请求伪造攻击的是浏览器会话,原因是同源策略允许跨域发起请求,当用户打开恶意页面发送伪造请求到 Server,刚好用户经过认证,浏览器会自动带上认证后的 Cookie 去执行此请求。

对于 Server 只要经过认证就执行你发过来的请求,前提是功能是当前这个角色有权限执行。

这个攻击能成前提是请求参数能猜出来(伪造),第二点是用户来触发这个伪造的请求,第三用户会话处于认证后的状态。

CSRF 漏洞站在业务上来看,对这个功能能造成多大危害,别忘了危害可以构造出来(扯反动和政治上的问题,在和开发撕逼的时候好用)。

self-xss 本身没有危害,自己乐呵呵呗,但结合 CSRF 可以在参数中写上 Payload,获取 COOKIE 达到持久化攻击的目的。

发现 CSRF 至少满足以下两条:

  1. 猜到 API 参数对应作用。
  2. 没有再校验机制,比如验证码、Token、Referer 等等再次验证身份的机制。

用户在线登录后访问一个恶意网页,以用户身份进行各种请求。

下面是 Burp 生成的 POC,手动修改了 button 换成 JS 自动提交表单。

<html>
    <head></head>
    <body>
        <form action="https://domain.com/index.ss" method="POST">
            <input type="hidden" name="参数名" value="参数值">
            <input type="hidden" name="参数名" value="参数值">
            <input type="hidden" name="参数名" value="参数值">
        </form>
        <script>
            document.forms[0].submit();
        </script>
    </body>
<html>

ByPass

bypass referrer,对于校验其中是否包含正确域名,可以添加子域名 abso.com.cn.eval.com,或是建立二级目录 eval.com/abso.com/index.html

DVWA 练习

下面这张图是修改密码时的包,这个包用 GET 传输,并且用 password_new 和 password_conf 参数来进行密码修改。这个等级下验证方式是 Rreferer。我们可以在本地搭建一个静态页面,把 Rreferer 跟测试站点调整一致,就可以绕过了。

csrfPacket.JPG

防御

伪造漏洞本质是加入不可猜测的内容保证随机化,有个词叫不可预测性(Unpredictable)。

  1. 使用 Token;每次请求后 Server 返回一段随机值放在 DOM 中,每次请求携着 Token 让 Server 校验这个请求是不是用户自己发送的。Token 存在 Cookie 字段中还需确认有没风险,因为同源策略无法获取其他标签页的 Cookie,只有在同源页面上 CSRF 才会攻击成功。
    关于 Token 黑皮书防止 CSRF 一节写到,会话没有与 Token 绑定,随便拿一个有效 Token 就行。如果 Token 生成规则容易被猜到也可伪造。
  2. 验证 Referer 来源,证明 Client 是从本站点访问的,换句话说是确认是用户自己发送的数据,而不是从一个其他域名上发起的请求。
  3. 采用再次验证机制确保请求是用户自己主动发出的,如手机验证码、滑动验证码,都是用来校验请求是人还是机器发送。

困境

设置 SameSite 能完全杜绝 CSRF?

Chrome 在 80 版本默认启用 SameSite 属性值设置为 Lax。SameSite 属性意义在于控制跨域请求 Cookie 是否携带,它有三个值,分别是 Lax、Strict 和 None。

Lax 是只有跨域 GET 请求可以携带 Cookie,Strict 只有跨域请求的 URL 和当前页面的一致 Cookie 才可以携带, None 就是不启用这个属性,Cookie 可以携带,设置为 None 有个限制,必须添加 Secure 属性用于确保传输用的是 HTTPS Cookie 才能发送。

看 twitter 有人研究出新的攻击手法,但是难度大大增加,只能说 CSRF 以后很难利用了。

参考资料:

标签: none

讨论讨论讨论!