是否可以信任会话Id的唯一性？

Question

我有一个古老的ASP经典web应用程序，当用户登录时为他们生成一个Id。Id被放入纯文本的身份验证cookie中，并存储在数据库中。

在这个网站里，我正在创建一个新的网站。因为它将具有相同的web域，所以它可以访问cookie。我的计划是查找cookie并使用Id在数据库中查找登录用户--就像典型的ASP站点所做的那样。

所以，我的问题是，这是一个安全风险吗？我认为机会是有人猜测生成的Id --在我看来，它在密码上并不安全。如果我编辑的ASP经典网站使用，比如说，一个GUID，这会是令人满意的独特吗？

我认为最弱的环节是原来的网站，所以新的网站不会使整个系统不那么安全。

Answer 1

虽然这里有一个公认的答案，但这有点误导人。

是否可以信任会话ID的唯一性？

如果唯一性是唯一的约束，那么简单的回答是肯定的。如果你是Facebook或Google，那么适当的扩展需要花费一些时间来评估基于算法和应用程序架构的碰撞的可能性。对于并发用户基数小于100万的应用程序，在公共平台上实现的方法应该足够了。

然而，唯一性只是解决了系统的功能。从安全的角度来看，您需要确保会话id是不可预测的，即

• 这不能从可用数据中推断；md5(CLIENT_IP)将是一个糟糕的会话id。
• 试图蛮力地猜测会话id是困难的；next_session_id=last_session_id+1将是一个糟糕的选择。

如果您确实必须实现您自己的会话id生成，那么使用一个好的随机数生成器。查看当前系统生成的会话in的大小，并在实现中至少以该大小为目标。

user52472说：

在数据库中存储会话令牌允许攻击者模拟其他用户，如果他们可以通过SQL注入攻击访问这些令牌的话。

考虑到服务器端会话的全部要点取决于服务器端存储，这可以更好地表述为：

在服务器上存储会话令牌可能允许攻击者劫持会话，如果它们能够注入读取存储的代码。

....although的本质是这样的，它通常是代码注入的低挂结果。

一种解决方案是不针对会话id存储会话数据，而是对其进行转换表示(例如，sha1(session_id + salt))，但这只能提供有限的好处--如果公开了salt和机制，则该机制是无效的。OTOH，这很容易翻译成其他存储基板。

如果会话存储在关系数据库中，则可以通过禁止应用程序使用的帐户直接访问基础表来防止枚举，相反，根据作为参数提供的具有特权分离的存储函数的键(会话id)，限制对单个记录的读和写。

Answer 2

你是对的，旧网站是最弱的环节。我看到了两个可能的弱点：

1. 会话令牌不是密码随机的。
2. 在数据库中存储会话令牌可以允许攻击者模拟其他用户，如果他们可以通过SQL注入攻击访问这些令牌。

对于第一个问题，这是一个获得密码安全的随机数的问题，并确保它有足够的比特。我不太熟悉经典的ASP，所以我无法告诉您实现这一目标的最佳方法。

对于第二个问题，我建议让框架处理所有的会话管理，无论何时您可以取消旧站点的委托。这也将解决第一个问题。