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

[LeeReamond]

一直在用开源库的 csrf token，最近想了一个问题是，比如权限这类信息，存在 cookies 里主要是为了防 xss，但是自然地就引入了 csrf 问题，而为了防御 csrf，后端还要再发一个能被 js 读取的 token，这不还是变回 xss 问题了么，万一出现 xss 漏洞，还是系统被攻破？

[LeeReamond]

@xiaoding 我概念没有搞混，你前三点和我说的一样，我想确认一下第四点是不是对的

[LeeReamond]

@abersheeran 我觉得你没有理解我说的话，你说的随机字符串的方案，就是我帖子一开始第一句说的 csrftoken，问题是我觉得既然 js 可以读取，那么还是会被 xss 漏洞攻破，如果出现的话，这种防御就没了意义。不如干脆不存在 cookie 里，可以断绝 csrf

[OHyn]

@ReinerShir 现在不少用 jquery 拼字符串的老网站还是有 xss 风险，过滤下挺好。。。。

[OHyn]

@LeeReamond 是，鉴权的 token 不放 cookie 里，直接解决 csrf 这种以蹭 cookie 为手段的攻击。chrome > 80, SameSite 默认 Lax，基本搞定 csrf 的问题了。

[Rocketer]

有一点需要特别明确——XSS 是指攻击者执行受害者在另一个网站的脚本，这个脚本通常还是官方的（比如在受害者不知情的情况下执行他网银的转账脚本）。

如果攻击者能执行另一个网站的自定义代码，那攻击者就无所不能了，因为他可以完整模拟受害者的身份了。CSRF 防御手段根本识别不出

[rodrick]

"这不还是变回 xss 问题了么"，这句话也没说错，但是防御 csrf 的前提是 xss 防护肯定得做好，包括 HTTP-only Cookie 只能算是其中一种防御方式
CSRF Token 是有弊端的，不是什么场合都可以使用的，一般如果自己做都是通过多种方式联合，虽然我也没实际做过但是理论上是这样。
你这个问题我刚学这玩意的时候也想过，后来想明白了其实这俩是完全不同的东西，不要捆绑在一起去思考

[rodrick]

@rodrick 关于 csrf token，理论上是这样的：”如果 同时被 XSS 攻击 ，攻击者先发起一次，用跨域方法绕过同源策略，就可以读取目标网站的 Token，甚至拿到 cookie“，所以发生这种情况的前提还是 XSS 做的有问题

[abersheeran]

@LeeReamond 是啊。CSRF 攻击本就是针对 Cookies 的设计缺陷。你都不用它了，自然攻击不到你。XSS 攻击就更宽泛，只要是浏览器里 JS 能做到的，XSS 攻击都可以做到。

[DOLLOR]

@OHyn 我见到现在许多还在固守 jquery 一把梭的，就喜欢拼接 html 字符串，然后$(xxxx).html(xxx)，简直是 XSS 的天堂。

[Asashiharuka]

父 token,禁止 ajax 获取 token