sessionId怕跨域问题,而token不怕的原因是不是因为前者是基于cookie自动携带而后者是手动携带?

发布于 2022-09-11 17:28:14 字数 409 浏览 45 评论 0

一般来说sessionId有跨域安全问题,而token却没有,我的理解是
sessionId怕跨域问题,而token不怕的原因是不是因为前者是基于cookie自动携带而后者是手动携带?
当有跨域攻击时,受害者点击链接会自动带上浏览器cookie上的sessionId
而token一般是程序员在程序中写ajax时,手动放在参数或者header中的,所以没有跨域安全问题?
如果token也放在cookie里,会和sessionId一样出现跨域安全问题
对不对?

那么像这种 https://blog.csdn.net/moshowg... zuul网关开放跨域应该没有安全问题吧?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

2022-09-18 17:28:14

不知道你说的跨域安全,是不是指CSRF?

如果是,那就先搞清楚csrf什么回事:

  1. 用户正常登录了A网站,生成了sessionid或者token
  2. 用户在未退出A时,访问了恶意站点B,B通过类似 <img src="A/xxx">的方式,偷偷以“用户身份”访问了A

再来看问题:

  1. 只要你登录了,就获得登录凭证(sessionid或token),这个凭证是你下次访问要传回给服务端的,所以,你要“保存”在客户端。
  2. 传统做法,sessionid是放在cookie的,这样,你下次访问,浏览器就会“自动带上”,但并不是“必须这样做的”。你了解session的原理后,sessionid同样可以放在header(甚至是get参数或post参数),只是这样,浏览器就不会自动带,需要你手工传了,这跟token放在header同一个道理。
  3. 回传的问题,通过src的方式隐藏调用,浏览器默认是会自动带上cookie的,但通过ajax调用默认好像是不带的(我写前端少,这个不确认)

所以,token放cookie其实有两层意思,一是保存在客户端cookie,二是 认证协议里的定义(传输方式)。 比如你将token放cookie了,但服务端认的还是header里的token,那你请求时自动在cookie里带上来的token是没有用的。

征﹌骨岁月お 2022-09-18 17:28:14

基于cookie的认证都存存在跨越安全问题,不管是自动的方式还是手动的方式,只不过token的方式是通过和认证中心经过几次重定向,将token传递给了其他域,题主参考下sso的认证过程就知道了,oath的认证过程也差不多。

记忆里有你的影子 2022-09-18 17:28:14

我也是这么觉得。

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文