cxrf攻击| 青训营笔记

109 阅读3分钟

这是我参与「第四届青训营 」笔记创作活动的第4天

cxrf攻击

跨站点请求伪造(Cross—Site Request Forgery)

  • 盗用用户身份登录其他网站 进行操作

image-20220720194812308.png

流程:

  • 受害者登录a.com,并保留了登录凭证(Cookie)
  • 攻击者引诱受害者访问了b.com
  • b.com 向 a.com 发送了一个请求:a.com/act=xx。浏览器会默认携带a.com的Cookie
  • a.com接收到请求后,对请求进行验证,并确认是受害者的凭证,误以为是受害者自己发送的请求
  • a.com以受害者的名义执行了act=xx
  • 攻击完成,攻击者在受害者不知情的情况下,冒充受害者,让a.com执行了自己定义的操作

预防:

  • 阻止不明外域的访问

    • 同源检测

      • Origin Header

        • 无法用前端进行修改
        • IE11不会在跨站请求添加Origin Header
        • 302的重定向请求也不会添加Origin Header
      • Referer Header

        • 由浏览器提供,有五种策略

        • 设置方法

          • 在CSP设置
          • 页面头部增加meta标签
          • a标签增加referrerpolicy属性
        • HTTPS页面跳转到HTTP页面,所有浏览器Referer都丢失。

    • Samesite Cookie

      • Samesite=Strict(严格模式)

        表明这个 Cookie 在任何情况下都不可能作为第三方 Cookie

      • Samesite=Lax(宽松模式)

        假如这个请求是这种请求(改变了当前页面或者打开了新页面)且同时是个GET请求,则这个Cookie可以作为第三方Cookie。

         Set-Cookie: foo=1; Samesite=Strict
         Set-Cookie: bar=2; Samesite=Lax
         Set-Cookie: baz=3
        

        我们在 a.com 下发起对 b.com 的任意请求,foo 这个 Cookie 都不会被包含在 Cookie 请求头中,但 bar 会。

        但假如这个请求是从 a.com 发起的对 b.com 的异步请求,或者页面跳转是通过表单的 post 提交触发的,则bar也不会发送。

        举个实际的例子就是,假如淘宝网站用来识别用户登录与否的 Cookie 被设置成了 Samesite=Strict,那么用户从百度搜索页面甚至天猫页面的链接点击进入淘宝后,淘宝都不会是登录状态,因为淘宝的服务器不会接受到那个 Cookie,其它网站发起的对淘宝的任意请求都不会带上那个 Cookie。

      • 缺点:

        • Samesite兼容性一般
        • 不支持子域
  • 提交时要求附加本域才能获取的信息

    • CSRF Token(可以使用分布式校验 token是一次计算的结果

      1. 将CSRF Token输出到页面中(token存在session中
      2. 页面提交的请求携带这个Token
      3. 服务器验证Token是否正确
    • 双重Cookie验证

      • 使用过程

        1. 在用户访问网站页面时,向请求域名注入一个Cookie,内容为随机字符串(例如csrfcookie=v8g9e4ksfhw)。
        2. 在前端向后端发起请求时,取出Cookie,并添加到URL的参数中(接上例POST www.a.com/comment?csr…)。
        3. 后端接口验证Cookie中的字段与URL参数中的字段是否一致,不一致则拒绝。
      • 缺点:

        1. cookie中增加了额外的字段
        2. 如果有其他漏洞(例如XSS),攻击者可以注入Cookie,那么该防御方式失效。
        3. 难以做到子域名的隔离
        4. 为了确保Cookie传输安全,采用这种防御方式的最好确保用整站HTTPS的方式
  • 保证页面的幂等性,后端接口不要在GET页面中做用户操作。