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页面中做用户操作。

avatar
文章
阅读
粉丝