1
lianyue 2023-03-09 00:48:53 +08:00
csrf 你不如需要安全操作的都是用 PUT PATCH DELETE 方法 HEAD GET POST 不允许用于安全的操作 更方便
|
2
Puteulanus 2023-03-09 01:34:53 +08:00 1
请求时通过 header 携带 sessionId ,意思是请求的时候用 JS 手动操作?那 sessionId 就必须在 JS 可操作的范围内,不像 HttpOnly 的 cookie ,那在 XSS 发生的时候会更危险
|
3
akira 2023-03-09 05:55:52 +08:00
有区别么,只要识别信息带过去了,就都一样
|
4
beginor 2023-03-09 08:01:08 +08:00 via Android
一个是浏览器行为,一个是 js 行为,不一样的。如果是 cookie 的话,浏览器自动按照地址发送 cookie ,而 local storage 里面的东西只能 js 主动发送,各有利弊
|
5
Al0rid4l 2023-03-09 08:16:04 +08:00
哪怕是 httponly 的 cookie, XSS 也是要防的, 还得防 CSRF, 存 Localstorage 好歹我只要防 XSS 就行, 我选 Localstorage, 当然如果要偷懒那就 cookie
|
6
xqk111 2023-03-09 09:06:38 +08:00
CSRF ,一般都是二次校验,苹果啊,支付啊,都是二次校验,加强安全性
|
7
nothingistrue 2023-03-09 09:30:03 +08:00
如果你的后台有分布式会话跟踪的需要,已经把 Session 改造成了 sessionId-redis 存储的形式,那么前端把 sessionId 的携带方式改造一下就没有问题。否则,就不要干这种杀鸡用牛刀的事,防 CSRF 很简单,不需要修改通用规范这么大的成本。
|
8
coolzjy 2023-03-09 09:44:32 +08:00 via iPhone
目前来看使用 JavaScript 手工管理凭据信息是更主流一些的方式:一来确实可以预防 CSRF ,更重要的是现代浏览器对于跨站 cookie 的限制越来越严格了,在跨域场景下使用 cookie 管理凭据已经基本不可行了。
|
9
dode 2023-03-09 10:27:32 +08:00
sessionId 就存在 cookie 里面的
|
10
yuezk 2023-03-09 10:28:57 +08:00
CSRF 的 token 和 sessionId 是两个东西,CSRF token 不需要长时间保存,最佳实践就是以 JS 变量或者隐藏字段的方式输出在页面中。
|
11
yodhcn OP @nothingistrue 确实如此,虽然 spring-session 支持 HttpSessionStrategy ,但是又没有分布式的需求,引入 spring-session 就有点多余。
但如果是前后端分离,比如前端在 a.com ,后端在 b.com ,这种情况又该怎样预防 CSRF ? |
12
yodhcn OP @nothingistrue 如果你说的是 spring-session ,它也可以用 MapSessionRepository 存储 session
https://stackoverflow.com/questions/28384907/can-i-enable-just-spring-session-header-authentication |