MVC 5 中的会话固定攻击仍然是一个问题吗

Posted 2023-03-08

【中文标题】MVC 5 中的会话固定攻击仍然是一个问题吗

【英文标题】：Are Session Fixation Attacks in MVC 5 still an issue

【发布时间】：2016-05-06 10:10:51

【问题描述】：

我已经阅读了很多关于会话固定攻击的内容，我遇到的最流行的解决方案是在用户登录时更改 SessionID，并使用 GUID 创建一个额外的 cookie 来验证用户“属于”SessionID .

我的问题是：仅删除 SessionID cookie (ASP.NET_SessionID) 以确保生成新的 SessionID 还不够吗？ 在 MVC 5 中，当用户登录时，会创建一个额外的加密用户声明 cookie (AspNet.ApplicationCookie)，Identity 使用该 cookie 在每次请求时对用户进行身份验证。额外的“GUID cookie”似乎没有必要。

我最初是一名 .NET 桌面应用程序开发人员，正在编写我的第一个 MVC 应用程序，学习曲线有点陡峭……虽然令人耳目一新。

感谢您的帮助。

【问题讨论】：

老实说，我刚刚发现了会话固定攻击，但这似乎是您问题的答案。 在验证用户时，它不会分配新的会话 ID，因此可以使用现有的会话 ID。在我看来，这意味着新生成的 cookie 也可能具有相同的会话 ID。不过，我可能错了。

How to protect my site from session fixation?的可能重复

@I.Am.Me 阅读这篇文章会帮助你codeproject.com/Articles/1116318/…

这里是会话固定问题的解决方案：***.com/a/51551957/3649347

【参考方案1】：

让我尝试通过桌面和网络应用程序（都在 .Net 中）之间的比较来解释问题和解决方案

当您启动桌面应用程序时，应用程序首先显示的是登录屏幕，之后您就可以访问 UI。现在，每次启动应用程序的 exe 时，它​​都会将“RunID”写入文本文件并显示登录屏幕。 RunID 是如何跟踪/关联您对应用程序的其余使用情况。

假设文件位于 C:\RunID.txt 上。

攻击者（黑客）可以在 Machine1 上启动 exe（无需登录）并将 C:\RunID.txt 的内容复制到 Machine2。现在，只要您登录 Machine1，来自 Machine1 的 RunID 令牌也将在 Machine2 上工作，这称为会话固定。

修复它的理想方法是放弃预身份验证令牌，并发出一个新的身份验证后令牌。因此，您将在身份验证后获得一个新令牌（或者在您的情况下，获得一个额外的 GUID），它不会在 Machine2 上存在，因此除了 RunID 随机令牌（会话 ID）之外还提供了一定程度的安全性

如果您想进一步解释，请告诉我，但这就是为什么即使在 MVC 中，您也应该放弃前一个会话并在身份验证后创建一个新会话以避免会话固定，作为补偿控制，您可以添加一个GUID cookie 也与 Session ID cookie 相对应。

【参考方案2】：

您可以这样做来避免这种情况：

SessionIDManager Manager = new SessionIDManager();

string NewID = Manager.CreateSessionID(Context);
string OldID = Context.Session.SessionID;
bool redirected = false;
bool IsAdded = false;
Manager.SaveSessionID(Context, NewID, out redirected, out IsAdded);
Response.Write("Old SessionId Is : " + OldID);

if (IsAdded)

     Response.Write("<br/> New Session ID Is : " + NewID);

else

     Response.Write("<br/> Session Id did not saved : ");

支持链接： Link

【讨论】：

不鼓励仅链接答案，请在此处分享链接中的一些上下文。