c# - session ID 不够随机 - ASP.NET

Question

更新

我们最终与 Acunetix 团队的一些程序员举行了一次 session ，他们意识到他们的代码中可能存在一些错误，导致这在扫描中显示为比实际可能更多的问题。普遍的共识是忽略扫描结果并使用开箱即用的 ASP.NET session ID 生成，因为它对我们的站点来说应该足够安全。

@Vasile Bujac 因为你的答案是唯一的一个并且提到了使用 ASP.NET 标准解决方案，所以我把它作为答案，但感谢大家的帮助。

我们在工作中使用 Acunetix 的 Retina 扫描仪对我们的应用程序进行安全扫描。它告诉我们，我们的 session ID 不够随机，也不够可预测。我不确定默认情况下 ASP.NET 是如何生成 session ID 的(我还以为它是 GUID？)，但我继续实现了扩展 SessionIDManager 类并覆盖 CreateSessionID 和 Validate 方法以使用 Guid 的方法如 this MSDN article 中所述.

虽然这使它稍微更随机，但根据 Acunetix 的说法，它仍然没有产生“期望”的效果。我什至添加了 regenerateExpiredSessionId="true"属性到 web.config 并且没有效果。我有一种感觉，我可能需要特意拨打Session.Abandon()真正清除 session 并获得新ID。问题是我必须在用户登录之前调用它，因为这是知道用户正在开始新 session 的唯一防故障方式。所以我不能在 session 中设置任何东西，直到下一页以 Abandon 的方式加载。方法有效，这意味着中间页面不是很理想，但可以解决问题。

有没有人经历过这种情况或成功实现了修复？

此外，仅供引用，我们不使用成员(member)/表单例份验证，我们只是在有人登录时创建一个新的自定义用户类并将其保存在 session 中以备后用。

来自 Acunetix 的报告:

CWE-330
CAPEC-59
OWASP2007-A7

说明:表现出低熵(“随机性”)的 session token 通常容易受到预测攻击。不安全的 token 可能是由于伪随机数生成器、基于时间的值、静态值或基于用户属性(用户名或用户 ID)的值不足造成的。这意味着攻击者可以在短时间监视应用程序并收集它创建的 session token 后猜测有效的 session token 。如果攻击者确定了另一个用户的有效 session token ，则可能无需猜测受害者的用户名或密码即可查看、修改或删除任意用户的数据。因此，推断有效 session token 的能力使攻击者能够绕过登录页面并避免暴力破解帐户的需要。此外，即使受害者当前未登录应用程序，静态 token 也可以使攻击者瞄准用户。这增加了攻击者可以瞄准的受害者池。

session token 应使用强大的随机数生成器创建，并从大量数字池中收集。例如，如果操作系统的 rand() 函数可以生成统计上均匀分布的 32 位值，它通常就足够了。较差的 session token 是增量的，依赖于用户的帐户 ID，仅使用时间戳，或具有其他高度确定性的信息。保护 session token 安全的其他方法是始终通过 SSL 传输它们，在一段时间后自动使 token 过期，并在用户退出应用程序时明确地使 token 过期。

推荐 :如果 session 值表现出很强的随机性，但是是从一个小的值池中选择的，那么攻击者就有更好的机会简单地猜测一个有效的 token 。可以通过实现几种互补技术来改进 Web 应用程序的 session 管理:

确保 Token 值的大小至少为 32 位，特别是对于具有大量并发用户和大量每日页面请求的应用程序。

熵源(随机值)的位大小比实际 session token 的位大小更重要。例如，一个 MD5 散列产生一个 128 位的值。但是，增量值的 MD5 哈希、时间戳或 8 位随机数均不安全，因为可以轻松预测随机值的来源。因此，128 位大小并不代表 session token 的准确度量。熵源的最小大小为 32 位，但对于每小时并发用户超过 10,000 的站点可能需要更大的池(48 或 64 位)。

在大多数情况下，应用程序生成的 token (例如 ASP.NET_SessionId、ASPSESSIONID、JSPSESSIONID、PHPSESSIONID)提供足够大的随机值来防止 session 预测攻击。应用程序应该使用这些 session 管理算法，除非自定义 session 机制已经过彻底审查和测试。

使用服务器端对象跟踪与 session token 关联的用户属性，以防止用户冒充攻击。如果应用程序没有将用户的 session token 与该用户的配置文件信息严格关联，那么攻击者可能能够通过操纵客户端值来查看任意信息。例如，如果应用程序设置了强 session token ，但根据“UserId”cookie 执行 SQL 查询，那么攻击者只需修改“UserId”cookie 即可冒充其他人。如果将“UserId”值与服务器端 session 对象相关联，应用程序将更加安全，因为攻击者将无法修改该值。

当用户退出应用程序或在预定的不事件时间后使 session token 过期。我们建议为 session token 使用 20 分钟超时，尽管这在很大程度上取决于应用程序的类型和预期的使用情况。

Answer 1

我记得，ASP.NET session ID 生成器对 session 预测提供了很好的保护。 session ID 有 24 个字符，使用 [a-z] 字符和 [0-5] 数字(总共 32 个可能的字符，即 2^5)，总共有 2^(5*24) = 2^120 个可能的值。但是，您可以实现一个 SessionIDManager 来附加一些信息(如用户主机地址、用户代理、使用 HMAC 算法的验证 token )以获得更好的保护 - 这样来自不同 IP 地址或不同浏览器的 session ID 就不会通过验证。如果您实现了表单例份验证，则没有必要，因为身份验证票已经提供了这些类型的保护。

如果您想要一个更好的随机 session ID，您可以在 SessionIDManager 中使用 RandomNumberGenerator(例如 RNGCryptoServiceProvider)并填充一堆字节(例如 32，即 256 位)，然后使用 Base64 对它们进行编码

byte[] random = new byte[100];
//RNGCryptoServiceProvider is an implementation of a random number generator.
RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();
rng.GetBytes(random); // The array is now filled with cryptographically strong random bytes.
return Convert.ToBase64String(random) 

然而， this article说您的 session ID 的最大长度是 80，因此您还必须覆盖 Validate 方法才能使其工作。