基于session实现用户登录？

  • Z时代
  • 2024-02-18
  • 分类：IT

问题描述

最近在研究基于session实现用户登录的功能时，突然对 服务端session校验的过程感到疑惑，之前都是通过拿到cookie中的sessionid然后通过session!=null去判断用户是否登录

那么问题来了，session是如何对不同的用户session有效性进行校验的？

以一个简单的登录网站举例，如果说用户A，没有注册但是通过浏览器的控制台在cookie里面随便编了一个JSESSIONID，这种情况下如果只看session是不是并不能判断出这个用户的真伪。

换句话说，sessionid只存在于用户浏览器的cookie中，而后端只是判session是否为空而不会去校验sessionid是后端生成的还是用户自己编造的？

另外如果A、B两个不同用户通过同一个session（比如都是A用户或者自己编的）都会判定其登录？而不会在意这个session是哪个用户的？

其实比较疑惑的地方就是在学这部分知识的时候，包括很多有关博文都说， 实现的原理是用户登录以后后端会生成一个唯一的sessionid存放在用户浏览器的cookie中，用户登录以后做的所有需要鉴权的操作都会先把之前的sessionid传回后端进行校验
但是几乎没有博文有说sessionid传回后端以后是怎么通过sessionid找到对应的用户并进行校验的

回答：

想的很好。但有一个误区。

首先 Session 无论是集中式还是分布式的，一定是存储在某个地方的。你可以想象成它是一个字典结构，而 SessionId 仅仅是一个 Key 而已。判断会话是否有效（也就是你所谓的用户是否登录）实际上是先判断 SessionId 是否在这个字典中存在、进而继续其他逻辑。而不是简单地看客户端传没传 SessionId 这个值。

换而言之，逻辑其实是：

boolean isLoggedIn = sessionMap.get(sessionId) != null;

而不是：

boolean isLoggedIn = sessionId != null && !sessionId.isEmpty();

当然了，这部分逻辑通常已经封装在你所使用的 Web 框架内部了。

那么问题就在于如何防止客户端伪造一个 SessionId、恰好这个值是有效的。这种攻击方式有一个专门的词来形容，叫“Session Prediction Attack”（Session 猜测攻击），你会看到有一些企业内网被攻破的案例中黑客就是采用了这种攻击方式。而对抗它的通常就那么几招：

  1. 确保 SessionId 的生成结果尽可能是离散的，这样就无法通过多个 Session 找出碰撞规律。
  2. 确保 SessionId 的长度足够，十年前的安全类文章会建议你 128 个字节，今天的话这个值再翻两倍也不为过。
  3. 确保 Session 的有效期不要太长（注意是 Session 的有效期、而不是 Cookies 的有效期，这两者是有区别的）。

回答：

一般情况下，Session ID 长度在 32 个字符左右，有的甚至可以长达 64 个字符，短的也有 16 个字符。这些字符一般由字母+数字组成，且部分还区分大小写，即至少由 26*2+10 个字符来随机组成一个 16 ~ 64 个字符的随机字符串，你要想随手就打出一个来可并不容易。

而且，只要你愿意，你甚至可以控制 Web 服务器每次请求都生成一个新的 Session ID，销毁旧的 Session ID。

你还可以自定义 Session ID 的生成方式。

听起来是不是有些像买彩票 ?

以上是 基于session实现用户登录？ 的全部内容， 来源链接： utcz.com/p/945206.html

回到顶部