如何传输 ASP.NET 会话状态对象？
为了减轻潜在的会话固定/陷阱攻击，我们需要能够在用户成功登录后将 ASP.NET 会话状态从一个会话 ID 转移到另一个会话 ID。用户在登录之前有重要的会话信息需要转移，因此我们不能只调用 Session.Abandon 或 Response.Cookies.Add(new HttpCookie("ASP.NET_SessionId", "")) 因为所有会话状态都会丢失。我们可以使用 System.Web.SessionState.SessionIDManager 调用 CreateSessionID()，然后调用 SaveSessionID() 来生成新的 ID，但同样，先前的状态会在下一个请求时丢失。所以我的问题基本上是如何将会话状态从登录前会话 ID 传输/关联到登录后会话 ID。
In order to mitigate potential Session Fixation/Trapping attacks, we need to be able to transfer the ASP.NET session state from one session Id to another after a user successfully logs in. A user has important session information before login that needs to be transferred, so we cannot just call Session.Abandon or Response.Cookies.Add(new HttpCookie("ASP.NET_SessionId", "")) as all the session state is lost. We can use System.Web.SessionState.SessionIDManager to call CreateSessionID() and then SaveSessionID() to generate a new ID, but again, the prior state is lost on the next request. So my question is basically how to transfer/correlate session state from a pre-login session Id to a post-login session Id.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
有很多文章和帖子解释了使用会话状态的潜在问题。最明显的是对多服务器环境的支持存在问题。
如果您将当前放入 Session[] 中的项目存储在数据库中或使用基于 SQL 的会话，那么“传输”只需将用户或连接与特定记录集相关联即可。
如果您绕过 Session 对象并自己处理所有事情（如果您想维护简单的 Session[] 键值接口，那么这是一项微不足道的任务），您将获得许多好处，例如在会话之间和跨应用程序之间保留的设置（如只要他们共享一个公共数据库）。
There are multiple articles and posts around that explain the potential issues with using Session state. The most obvious is problematic support for multi-server environments.
If you store the items that you're currently putting in Session[]in a database or use SQL-based sessions, "transferring" is simply a matter of associating a user or connection with a particular record set.
If you bypass the Session object and handle everything yourself, which is a trivial task if you want to maintain the simple Session[] key-value interface, you get a number of benefits, such as settings that persist between sessions and across applications (as long as they share a common database).