具有 2 个会话（用户 ID、用户名）的用户，不安全？ [关闭]答案

【问题标题】：User with 2 sessions (userid, username), insecure? [closed]具有 2 个会话（用户 ID、用户名）的用户，不安全？ [关闭]
【发布时间】：2013-11-17 22:33:55
【问题描述】：

如果有人登录，我会保存 2 个会话。

Session["userid"]
Session["nickname"]

Session["userid"] 用于从数据库中检索有关用户的数据。

Session["nickname"] 用于将用户重定向到他的个人资料页面

（例如：www.test.com/mike（在这种情况下，''Mike'' 是昵称）。

我想知道这个想法是否安全？是否建议这样做，还是有其他更好的选择？

【问题讨论】：

您的意思是“在这种情况下，''Mike'' 是昵称”，对吗？
糟糕，我指的是昵称，而不是用户名。谢谢。
你不需要存储用户id，只要登录到任何页面使用Membership.GetUser(HttpContext.Current.User.Identity.Name).ProviderUserKey就可以检索到
Hacking session variables in Asp.NET的可能重复
@andleer 会话并非本质上是安全的。直接抓取 cookie 或嗅探网络，您就可以冒充其他用户。

标签： c# asp.net security session web

【解决方案1】：

您不是在存储两个会话，而是在会话中存储两个变量。拥有两个变量从根本上来说并没有什么问题，我唯一的想法是如果 nickname 更新会发生什么？每次使用userid 作为键而不是在登录后固定一个静态变量不是更好地从数据库中查找昵称吗？

话虽如此，为此使用 Forms Authentication Ticket 比使用 Session 更安全。看到这里有一些很好的理由：https://stackoverflow.com/a/18077422/413180

【讨论】：

【解决方案2】：

我认为那里没有什么大问题，除非某个用户的昵称可以稍后更改。在这种情况下，用户个人资料的 URL 会发生变化，您应该正确调整所有链接。

对于 URL，我会使用 UID。并将其存储在 SESSION 变量中。例如，如果用户更改 SESSION 变量之一的值会发生什么？你会在每次页面加载时验证它吗？

【讨论】：

“如果用户更改 SESSION 变量之一的值会发生什么” - 用户将如何做到这一点？
我们没有看到页面的整个代码，所以我们不知道这些变量是如何设置和修改的。也许通过发送一个 POST/GET 参数，这个值在 SESSION 变量中被改变，但在 DB 中没有改变，...

【解决方案3】：

数据是安全的还是不安全的，数据是否存储在两个单独的Session 对象中并不重要。所以如果用户ID或昵称可以被某人恶意使用，那么它是不安全的；否则不会。

我通常将用户信息存储在一个名为 LoggedOnUser 的单个 Session 对象中，它代表一个类的实例。在您的情况下，创建一个仅包含两条信息的类可能有点矫枉过正。

我建议不要仅将昵称用作 URL，因为如果 nickname 值发生变化怎么办？用户 ID 似乎更合适，因为它不太可能改变，如果有的话。这就是 StackOverflow 对您的用户个人资料 (stackoverflow.com/users/YOUR_USER_ID/YOUR_NICKNAME) 的处理方式，如果您以前有昵称，那么旧昵称将根据您的用户 ID 值映射到当前昵称。

【讨论】：

补充一点，处理这个问题的常用方法是创建一个类似 www.test.com/123/mike 的 URL，其中 123 是用户 ID，mike 是昵称。然后，您的应用程序将忽略 mike 部分，只查看 id... 但 URL 仍然是人类可读的。此页面的 url 是这样的：/questions/123/user-with-two... 等等。如果您编辑地址栏并更改末尾的纯文本部分，页面仍然会加载，因为它被忽略了。跨度>
@JohnGibb - 关于人类可读、类似 REST 的 URL 的同意和好点。

【解决方案4】：

简答：不安全

如果您不使用 SSL，用户会话可能会被特别劫持，这只是时间问题，并且取决于一些因素，例如黑客的专业程度、她拥有的设施等。作为一种解决方案，我建议您使用Forms Authentication。
如果您仍然坚持使用 Session 来存储此类敏感信息，那么我建议您生成一个临时密钥（例如 GUID）和将该键与用户对象关联特定时间（您需要将此键存储在数据库中）。您还可以将更多信息绑定到此密钥，例如客户端的 IP 地址。将此临时密钥存储在 Session 中，并仅在此密钥有效且 IP 地址没有可疑更改时处理请求。

【讨论】：