会话 ID 不够随机 - ASP.NET

UPDATE

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

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

我们在工作中使用 Acunetix 的 Retina 扫描仪对我们的应用程序进行安全扫描。它告诉我们，我们的会话 ID 不够随机且太可预测。我不太确定 ASP.NET 默认情况下如何生成会话 ID（我认为它是 GUID？），但我继续实现了扩展 SessionIDManager 类并重写 CreateSessionID 和 Validate 方法以使用 Guid 的方法如中所解释的这篇 MSDN 文章 http://msdn.microsoft.com/en-us/library/system.web.sessionstate.sessionidmanager.createsessionid.aspx.

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

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

另外，仅供参考，我们不使用成员资格/表单身份验证，我们只是在有人登录时创建一个新的自定义用户类并将其保存在会话中以供以后使用。

Acunetix 的报告：

CWE-330 http://cwe.mitre.org/data/definitions/330.html CAPEC-59 http://capec.mitre.org/data/definitions/59.html OWASP2007-A7 https://www.owasp.org/index.php/Top_10_2007-A7

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

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

建议：如果会话值表现出很强的随机性，但是从一小部分值中选择的，那么攻击者就有更好的机会简单地猜测有效令牌。可以通过实施几种补充技术来改进 Web 应用程序的会话管理：

• 确保 Token 值的大小至少为 32 位，特别是对于并发用户数量较多且每日页面请求量较大的应用程序。
• 熵源（随机值）的位大小比实际会话令牌的位大小更重要。例如，MD5 哈希会生成 128 位值。然而，增量值、时间戳或 8 位随机数的 MD5 散列都是不安全的，因为可以轻松预测随机值的来源。因此，128 位大小并不代表会话令牌的准确度量。熵源的最小大小为 32 位，但对于每小时超过 10,000 个并发用户的站点可能需要更大的池（48 或 64 位）。
• 在大多数情况下，应用程序生成的令牌（例如 ASP.NET_SessionId、ASPSESSIONID、JSPSESSIONID、PHPSESSIONID）提供足够大的随机值以防止会话预测攻击。应用程序应该使用这些会话管理算法，除非自定义会话机制已经过彻底的审查和测试。
• 使用服务器端对象跟踪与会话令牌关联的用户属性，以防止用户模拟攻击。如果应用程序没有严格地将用户的会话令牌与该用户的配置文件信息相关联，则攻击者可能能够通过操纵客户端值来查看任意信息。例如，如果应用程序设置了强会话令牌，但基于“UserId”cookie 执行 SQL 查询，则攻击者只需修改“UserId”cookie 即可冒充其他人。如果应用程序将“UserId”值与服务器端会话对象相关联，那么应用程序将更加安全，因为攻击者将无法修改该值。
• 当用户注销应用程序或在预定的不活动时间后，会话令牌将过期。我们建议对会话令牌使用 20 分钟的超时，尽管这很大程度上取决于应用程序的类型和预期的使用情况。

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

如果您想要更好的随机会话 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) 

然而，本文 http://msdn.microsoft.com/en-us/library/system.web.sessionstate.sessionidmanager.sessionidmaxlength.aspx表示会话 ID 的最大长度为 80，因此您还必须重写 Validate 方法才能使其正常工作。