V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
FONG2
V2EX  ›  程序员

讨论一下本地发起的 POST 能不能算为 CSRF 攻击

  •  
  •   FONG2 · 2018-02-06 12:20:14 +08:00 · 7211 次点击
    这是一个创建于 2469 天前的主题,其中的信息可能已经有所发展或是发生改变。

    最近集团换了一个安全公司为网站做渗透测试,

    出了一份漏洞报告:

    大体内容为,黑客可以用 CSRF 方式修改用户个人信息,条件系黑客写好 post form 保存为 test.html 并把 test.html 存放在被攻击者本机,诱导被攻击者打开该文档 或将 test.html 放在我司域名服务器,诱导客户点击

    我司网站已经配置了全局 csrf 过滤器,检查 refer 字段匹配白名单

    本地首次请求 refer 为空,可以成功 在我司域名服务器 refer 合法,可以成功

    但是??? 黑进客户电脑 /我司服务器 这种情况来说一个修改个人信息漏洞 没事吧??

    第 1 条附言  ·  2018-02-07 09:35:33 +08:00
    以上问题已在 csrf 过滤器之后曾加 session token 校验

    但是 csrf 的经典场景不应是 a 站内嵌 b 站 post,用户登录 b 站并打开 a 站,导致被攻击?

    我的情景是:用户没有打开任何域名页面,只是打开了 file:///C:/Users/Admin/Desktop/test.html
    第 2 条附言  ·  2018-02-07 09:37:37 +08:00
    另一个场景 黑客攻破我司服务器,放置一个内嵌 post 的 html,地址为:www.我司域名.cn/test.html 用户点击被攻击
    45 条回复    2018-03-04 22:15:43 +08:00
    yulitian888
        1
    yulitian888  
       2018-02-06 12:27:07 +08:00
    如果是办公环境的话,邮件 /QQ 诱导点击的成功概率并不低啊,真的不要高估工作人员的素质
    xomix
        2
    xomix  
       2018-02-06 12:28:15 +08:00
    所以后台要发 token ……这样你随便 post,你有能用的 token 算我输。
    FONG2
        3
    FONG2  
    OP
       2018-02-06 12:32:01 +08:00
    @yulitian888 如果客户随便打开陌生文件,这个安全危害更大啊
    qlin
        4
    qlin  
       2018-02-06 12:35:02 +08:00
    简单的做个跨资源访问限制 + content-type 限制,就差不多了
    FONG2
        5
    FONG2  
    OP
       2018-02-06 12:42:16 +08:00
    @xomix 是的,像这种无风险业务我觉得屏蔽 get,屏蔽跨域 post,保证客户不是被动发起非法请求,至于关键业务我们是有二次鉴权的。
    leir
        6
    leir  
       2018-02-06 12:45:25 +08:00 via Android
    为啥不使用 csrf token ?
    Zzzzzzzzz
        7
    Zzzzzzzzz  
       2018-02-06 12:49:06 +08:00
    "本地首次请求 refer 为空,可以成功 在我司域名服务器 refer 合法,可以成功"

    如果这种方式能成功

    通过诱导用户访问不发送 referer 的 ssl 页面用 js 自动提交不也可以么
    caola
        8
    caola  
       2018-02-06 12:51:56 +08:00
    为啥不使用 csrf token ? +1
    40huo
        9
    40huo  
       2018-02-06 12:55:46 +08:00 via Android
    这是标准的 csrf
    jimrok
        10
    jimrok  
       2018-02-06 13:01:28 +08:00
    发一个够劲爆的邮件给你,一点链接直接黑掉你的浏览器,把木马植入进去。还用干什么 form post,low 了点。
    fcten
        11
    fcten  
       2018-02-06 13:04:22 +08:00
    没有严格检查用户输入导致网页被植入恶意脚本是很有可能发生的事情。检查 refer 不能防止这种典型的 csrf 攻击。
    DuckJK
        12
    DuckJK  
       2018-02-06 13:09:00 +08:00
    如果 referer 为空放行了请求,在 https 或 iframe 的 base64 是可以请求成功的。
    zarte
        13
    zarte  
       2018-02-06 14:07:32 +08:00
    都黑进去放东西了还要诱导?
    fucker
        14
    fucker  
       2018-02-06 14:11:39 +08:00
    我觉得还是加强一下员工安全意识吧。
    tvboxme
        15
    tvboxme  
       2018-02-06 15:12:43 +08:00
    这就是漏洞啊,现在多少框架都自带 csrf token 了,长点心吧。。
    BoiledEgg
        16
    BoiledEgg  
       2018-02-06 15:16:01 +08:00
    仅仅验证 refer 本来就不足以防范 csrf 的,csrf token 是必须的
    ushio
        17
    ushio  
       2018-02-06 15:44:47 +08:00
    不要寄望于公司员工能有多高的安全意识
    Koali
        18
    Koali  
       2018-02-06 16:54:35 +08:00
    这种漏洞只需要发送请求的时候给个随机数就可以了
    lightening
        19
    lightening  
       2018-02-06 17:03:44 +08:00
    为什么不用 CSRF token ?+1
    picasso250
        20
    picasso250  
       2018-02-06 17:31:02 +08:00
    我之前在公司做过一次演习,用假域名做了 fish 站,只有一个登录界面.
    然后发了一封邮件(用外网邮箱), 结果拿到了 5%用户的密码.
    FONG2
        21
    FONG2  
    OP
       2018-02-06 17:45:10 +08:00
    @picasso250 我就是这个想法,我做到浏览器内的防跳转保护足以,至于用户是否有足够的安全意识我保证不了
    如果用户随意打开陌生文件,加 token 其实也是防不住的
    husky
        22
    husky  
       2018-02-06 18:20:36 +08:00
    想请教下楼主准备怎么处理这个漏洞
    menc
        23
    menc  
       2018-02-06 18:57:19 +08:00   ❤️ 1
    算典型的安全漏洞。
    现在的安全渗透不像你想象的那种,一条路走到黑。现在的安全渗透流行个黑话叫 APT,讲究一个步步为营长期渗透稳扎稳打,社会工程学,翻垃圾桶,公司楼下蹭 WIFI,和公司人员拉关系,都是安全渗透的一环。很多安全案例本身就是首先黑进一个员工电脑,再进行后续其他操作。
    所以是安全漏洞,要防范。

    给一个建议,安全水很深,虽然是计算机行业,但是和码农不是一个领域,在他们的领域建议听他们的。
    falcon05
        24
    falcon05  
       2018-02-06 19:03:53 +08:00 via iPhone
    本地首次请求 refer 为空,可以成功 在我司域名服务器 refer 合法,可以成功

    首次 referer 为空也能成功?你这不但没 csrf token,对 referer 的检查也怪怪的。什么鬼
    FONG2
        25
    FONG2  
    OP
       2018-02-06 20:02:47 +08:00
    @menc 按他们的说法加 token 了,但是就算加 token 我还是想到一百种破解。。。如果用户随便打开脚本

    但是我也要说明一下,我们关键业务 都有二次鉴权的
    ytmsdy
        26
    ytmsdy  
       2018-02-06 20:19:01 +08:00 via iPhone
    算啊!假如在一个内网和外网都通的环境下,在外网的网页上加入自动 post 到内网网站的 form !
    jackmasa
        27
    jackmasa  
       2018-02-06 21:59:02 +08:00
    @FONG2 不用本地也可以做到空 referer 的,改吧,目前 session token 是最有效的手段。
    breeswish
        28
    breeswish  
       2018-02-07 00:04:32 +08:00
    @FONG2 加 token 不能破解的,除非在同域下(不信的话说个方法出来)
    binux
        29
    binux  
       2018-02-07 00:11:59 +08:00 via Android   ❤️ 1
    按照你的说法,反正用户电脑会被黑,那用户密码也不要有了,填个用户名就让登录就行了,反正关键业务有二次鉴权。
    FONG2
        30
    FONG2  
    OP
       2018-02-07 09:09:45 +08:00
    @binux 你这是以极少数否定全部哦
    FONG2
        31
    FONG2  
    OP
       2018-02-07 09:10:18 +08:00
    @ytmsdy 这种会拦截的
    slgz
        32
    slgz  
       2018-02-07 10:16:51 +08:00
    @menc 这么高级的吗= =。我现在就是一个码农,但是,公司想让我转这个方向。
    FONG2
        33
    FONG2  
    OP
       2018-02-07 10:20:05 +08:00
    @slgz 如果有资源学得很快的,我一年前还在上学天天打游戏。。。
    经历半年和安全公司打交道,看看文档、聊聊天。常见攻击方式、原理都懂了
    只是今年换了个安全公司,把本地脚本 post 也算 csrf 一时没适应过来
    DOLLOR
        34
    DOLLOR  
       2018-02-07 10:26:41 +08:00
    如果检查 referer 的合法性,至少能防范外部网站、本地文件、DataURL 页面的跨站请求伪造。

    如果是“另一个场景 黑客攻破我司服务器,放置一个内嵌 post 的 html,地址为:www.我司域名.cn/test.html 用户点击被攻击”,这明显已经不是 CSRF 了,CSRF 本意就是跨站请求伪造(注意“跨站”),而你这个例子已经是你自己站点被黑了。不是你防住了 CSRF 就能避免的。根本办法还是防止你的网站被黑。
    slgz
        35
    slgz  
       2018-02-07 10:29:47 +08:00
    @FONG2 公司,现在就是让我独立干。但是,写代码的事情也不能落下。现在,完全都是用阿里云的产品,包括服务器、web 防火墙之类的,感觉,完全接触不到,正经人。只能自学,但是,最近代码任务也重,感觉没时间去
    SlipStupig
        36
    SlipStupig  
       2018-02-07 10:38:57 +08:00
    很多邮件客户端为了支持 HTML 解析,集成了 webkit,比如: foxmail < 7.0,只发一个邮件,都不用你点,只要你收到了就可以可以在本地执行 JS, 你说的本地场景 1,是理论可行, 至于场景 2 完全是多此一举
    SlipStupig
        37
    SlipStupig  
       2018-02-07 10:41:31 +08:00
    场景 1:完全可以通过恶意 JS, 去控制员工机器然后去做跳板,这种 CSRF 已经不属于伪造范畴了,也是正确的废话
    FONG2
        38
    FONG2  
    OP
       2018-02-07 11:21:33 +08:00
    @DOLLOR bingo 文档提供者原话就是这样举例的
    我都不知道怎么跟他聊天 一个中低程度漏洞,条件要扯上服务器被黑、用户被黑,搞得我相当反感
    FONG2
        39
    FONG2  
    OP
       2018-02-07 11:25:52 +08:00
    @SlipStupig 是的,我觉得,场景 1 算为 csrf 漏洞有点牵强,要 100%安全,是不是每一个请求都要来一个人机识别校验?但是漏洞确实可以这样被利用,OK,我加了 session token。
    场景 2 在讨论的时候我都想爆粗了
    FONG2
        40
    FONG2  
    OP
       2018-02-07 12:26:54 +08:00 via iPhone
    @SlipStupig 我还有一个疑问,场景一是建立在用户已登录且保持登录状态的情况下的,邮件客服端发起的请求能带上默认浏览器的 cookie 吗?
    mitnick
        41
    mitnick  
       2018-02-07 14:23:36 +08:00
    单从技术角度出发这属于标准的 CSRF 攻击,但是至于说危害和影响,另算
    binux
        42
    binux  
       2018-02-08 01:41:00 +08:00
    你允许 referere 为空,是无法防范「 a 站内嵌 b 站 post,用户登录 b 站并打开 a 站,导致被攻击」的,a 站有很多种方法让 refereer 为空。
    wizardforcel
        43
    wizardforcel  
       2018-02-08 09:54:01 +08:00
    算文件上传。

    只要你的站点有 XSS 或者文件上传漏洞,所有 CSRF Token 全部白费。

    文件上传这种低级漏洞现在都很少见了,不要为了防止高级漏洞而忽视了这种低级的。
    SlipStupig
        44
    SlipStupig  
       2018-02-08 10:53:31 +08:00
    @FONG2 既然我能本地执行 js,我肯定会进行权限提升,然后得到你浏览器保存的所有数据,为什么还要绕这么大一个圈呢?
    PHPer233
        45
    PHPer233  
       2018-03-04 22:15:43 +08:00 via iPhone
    即使你用 token 验证也不是绝对安全。如果你的网站存在 xss 漏洞,那么黑客可以通过 ajax 获取 token,然后再通过 ajax 自动发送 http 请求。全过程用户毫无感知~我建议所有的敏感操作都要附带 token,从一定程度上防止 csrf 攻击。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2930 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 14:26 · PVG 22:26 · LAX 06:26 · JFK 09:26
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.