相关疑难解决方法(0)

我正在生成一个加密密钥,用Rijndael(AES)加密算法加密一些敏感数据.我正在使用guid作为密钥生成器.这些钥匙"足够"吗？

_{注意:它只对20分钟敏感.}

UPDATE

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

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

我们在工作时使用Acunetix的Retina扫描仪对我们的应用程序进行安全扫描.它告诉我们,我们的会话ID不够随机且太可预测.我不确定ASP.NET默认情况下如何生成会话ID(我认为它仍然是GUID？),但我继续实现了扩展SessionIDManager类并重写CreateSessionID和Validate方法以使用Guid的方法正如本MSDN文章中所述.

虽然这使得它稍微随机,但仍然没有产生Acunetix的"期望"效果.我甚regenerateExpiredSessionId="true"至将属性添加到web.config并且没有任何效果.我有一种感觉,我可能需要刻意打电话Session.Abandon()来真正清除会话并获得一个新ID.问题是我必须在用户登录之前调用它,因为它是唯一一种知道用户正在开始新会话的防故障方式.所以我无法在会话中设置任何内容,直到下一页加载了Abandon方法的工作方式,这意味着中间页面不是很理想,但可以做到这一点.

有没有人经历过这个或成功实施过修复？

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

来自Acunetix的报告:

CWE-330 CAPEC-59 OWASP2007-A7

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

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

建议:如果会话值表现出强烈的随机性,但是从一小部分值中选择,则攻击者更有可能简单地猜测一个有效的令牌.通过实现几种互补技术,可以改进Web应用程序的会话管理:

• 确保令牌值至少为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的基础函数？我想生成一个用于Web服务的会话令牌,但它不会放在Set-Cookie头中.如果ASP.NET已经有一个我可以用来生成会话ID的函数,这将使我不必自己滚动.