问题标签 [asp.net-session]

场景：我有一个在 Silverlight (4) 中开发的 PRISM 应用程序，并且我正在使用 ASP.NET 服务器端应用程序来托管多个 Web 服务（反过来，它访问 WCF 服务，但这在这里并不重要）。Silverlight 应用程序必须能够跨域调用 Web 服务（这意味着 Web 服务不一定在托管 silverlight 应用程序的同一台服务器上）。

Silverlight 应用程序由几个模块组成，每个模块都访问 ASP.NET Web 服务。

我对 Silverlight 和 PRISM 没有太多经验，但据我所知，这并不是一个非常不寻常的场景......

问题：我的挑战是，当 2 个不同的模块访问 Web 服务时，我会在 Web 服务器上获得 2 个新会话。我会认为由于两个模块都存在于同一个 HTML 页面上（然后也在同一个浏览器会话中），它们会在网络服务器上获得相同的会话......？

我试图通过注册一个实例（使用 Container.RegisterInstance），然后在模块需要进行 Web 服务调用时获取该实例（使用 Container.Resolve），但这似乎没有帮助。

但是，在同一模块中进行的任何调用始终会在服务器上获得相同的会话。

谁能看到我在这里想念的东西......？

谢谢！

乔恩

我的问题是，当我在单独的 IE 窗口中从 Outlook 打开 Web 应用程序时，ASP.NET 会话丢失。这是（如多处所述）因为内存中的 cookie 丢失了。

所以它是这样的：

1. 用户在 Outlook 中使用 ASP.NET Web 应用程序，这会在 ASP.NET 会话中存储一些信息
2. 用户单击打印以打开带有打印就绪数据的新 IE 窗口
3. 新窗口具有不同的 ASP.NET 会话 ID，无法访问旧数据。

我想，也许，如果我将 ASP.NET 会话 ID 传递给新的 IE 窗口，我可以以某种方式“附加”到那个会话？告诉 ASP.NET 这是我需要更新的那个吗？

据我所知，目前的情况是这样的：

1. 使用 SQL 会话状态提供程序是可能的（正如我在某处读过的那样），但 Microsoft 不支持它。所以它可能在未来停止工作。它还需要一个 WorkerRole 来删除过时的数据。
2. Azure AppFabric 缓存服务仍在 CTP 中。
3. TableStorageSessionProvider 是 Azure 培训工具包中的一段代码，不建议用于生产代码。

你会选择什么？

我正在尝试使用 Azure 培训工具包中的 TableStorageSessionStateProvider。我可以毫无问题地使用该示例，但是当我在我的网络应用程序中使用它时，我得到了这个异常：

我已经尝试过了，但到目前为止没有运气。我还看到发生空引用异常，所以我猜 TableStorageSessionStateProvider 它的行为不像 InProc 那样，所以也许我必须检查会话在应用程序中的使用方式. 但是，可能是什么问题？

编辑：好吧，我发现如果您只使用 TableStorageSessionStateProvider 相同的例外情况，Azure 培训工具包中的示例也会失败。您只需评论其他提供者：

我的应用程序中有 2 个页面：Login.aspx 和 Home.aspx。

现在，如果用户没有登录，他不应该从 Web 浏览器访问 Home.aspx。

我知道这可以通过会话实现，但不知道如何实现。

让我知道该怎么做？

谢谢！

我正在完成一个启动另一个程序员的项目。改变整个架构是不可能的，但有些东西我想覆盖。即 - 授权，以及存储当前用户会话的方式。该项目代表一个通过soap-services与服务器通信的客户端。在服务器上，有 Security-Services，还有其他几个，例如 A-service、B-Service。安全服务提供用于初始化其他服务的身份验证和会话密钥。该项目是用 ASP.NET MVC3 编写的，它是一个用户模型的头部，它被实现为 singletone-Class，它描述了与服务交互的方法。授权是如何工作的 - 有一个带有重写 ValidateUser 方法的 CustomMembershipProvider，它在安全服务上运行。

主要问题是现在会话存储在内存中：web.config：

设置 SqlServer-mode 是有问题的，因为它很难将 SiteUser 序列化。我怎样才能解决这个问题？并且授权存在问题 - 如何正确地使用服务会话进行 Asp.Net 同步会话？对不起我的英语，如果需要澄清 - 问问题。谢谢你。

编辑

这个问题似乎奇怪地消失了。我的环境一定有什么奇怪的地方。我投票结束这个问题。

当用户登录时，我使用来自登录页面代码隐藏的一堆数据来扩充会话。然后我将用户重定向到应用程序中的不同页面。我还有一些会话恢复逻辑，当用户会话过期时，它会根据身份验证票重新膨胀会话。

似乎正在发生的事情是，我用登录页面中的一堆数据膨胀了用户的会话，然后将它们重定向，而我将它们重定向到的页面的请求似乎没有会话，所以应用程序有重新充气。我不明白这一点 - 我查看了 cookie 并且会话 ID 没有更改，并且我没有在代码中的任何位置重置会话数据。这是 ASP .NET 的“功能”吗？我正在使用 ASP .NET 4.0。

编辑：

澄清一下：在登录请求期间会话被夸大了（甚至在登录按钮的点击上）。在下一个请求期间，似乎不再填充会话，因此我最终不得不重新填充会话。用户在此之后提出的任何请求，会话似乎都“坚持”并且我为后续请求提供了适当膨胀的会话。

我正在使用 asp.net 并将会话配置为存储在 SQL 服务器中。我的项目有很多对象和几个 linq-to-sql dbml。我已将它们全部配置为具有单向序列化，并进行了一些自定义更改。

当我运行应用程序时，我的 application_error 事件处理程序中不断收到此错误

在程序集“App_Code.thzd8p2j, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null”中键入“Data.Karaoke.spCWP_SelUserPrivilegesResult”未标记为可序列化。

从错误我不确定它是否来自 dbml.designer.cs 文件，这是代码：

和

如何确定错误的来源？或者错误是什么意思？

我不确定如何解决或寻找什么来解决问题。

我有两个网址。如果我打开第一个 url，它将允许我们进行身份验证。第二个 URL 将 Web 内容作为 XML 数据打开。我需要读取该数据...但是当我执行第一个 URL 时，它的工作正常 Authentication 是 SUCCESS，但是我立即尝试打开第二个 URL，它说 Authentication failed 。如何维护从第一个 URL 到第二个 URL 的会话...

我的代码：

更新

我们最终与 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方法的工作方式加载，这意味着中间页面不是很理想，但可以解决问题。

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

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

来自 Acunetix 的报告：

CWE-330 CAPEC-59 OWASP2007-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 分钟超时，但这在很大程度上取决于应用程序的类型和预期的使用情况。