V2EX = way to explore
V2EX 是一个关于分享和探索的地方
Sign Up Now
For Existing Member Sign In
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 1145 days ago, the information mentioned may be changed or developed.
如果用 localstorage 替代 cookie 是不是就不存在 csrf 问题了？
cookie 随请求自动携带的特性，是不是 csrf 问题的主要原因？
localstorage 存储 sessionId + 请求时通过 header 携带 sessionId 的这种方式，与传统的通过 cookie 存储与携带 sessionId 的方式相比，哪种方式更好？
cookie 随请求自动携带的特性，是不是 csrf 问题的主要原因？
localstorage 存储 sessionId + 请求时通过 header 携带 sessionId 的这种方式，与传统的通过 cookie 存储与携带 sessionId 的方式相比，哪种方式更好？
 |
1
lianyue Mar 9, 2023
csrf 你不如需要安全操作的都是用 PUT PATCH DELETE 方法 HEAD GET POST 不允许用于安全的操作 更方便
|
 |
2
Puteulanus Mar 9, 2023  1
请求时通过 header 携带 sessionId ，意思是请求的时候用 JS 手动操作？那 sessionId 就必须在 JS 可操作的范围内，不像 HttpOnly 的 cookie ，那在 XSS 发生的时候会更危险
|
 |
3
akira Mar 9, 2023
有区别么，只要识别信息带过去了，就都一样
|
 |
4
beginor Mar 9, 2023 via Android
一个是浏览器行为，一个是 js 行为，不一样的。如果是 cookie 的话，浏览器自动按照地址发送 cookie ，而 local storage 里面的东西只能 js 主动发送，各有利弊
|
 |
5
Al0rid4l Mar 9, 2023
哪怕是 httponly 的 cookie, XSS 也是要防的, 还得防 CSRF, 存 Localstorage 好歹我只要防 XSS 就行, 我选 Localstorage, 当然如果要偷懒那就 cookie
|
 |
6
xqk111 Mar 9, 2023
CSRF ，一般都是二次校验，苹果啊，支付啊，都是二次校验，加强安全性
|
 |
7
nothingistrue Mar 9, 2023
如果你的后台有分布式会话跟踪的需要，已经把 Session 改造成了 sessionId-redis 存储的形式，那么前端把 sessionId 的携带方式改造一下就没有问题。否则，就不要干这种杀鸡用牛刀的事，防 CSRF 很简单，不需要修改通用规范这么大的成本。
|
 |
8
coolzjy Mar 9, 2023 via iPhone
目前来看使用 JavaScript 手工管理凭据信息是更主流一些的方式：一来确实可以预防 CSRF ，更重要的是现代浏览器对于跨站 cookie 的限制越来越严格了，在跨域场景下使用 cookie 管理凭据已经基本不可行了。
|
 |
9
dode Mar 9, 2023
sessionId 就存在 cookie 里面的
|
 |
10
yuezk Mar 9, 2023
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 |
Select Language