我读了很多关于 session 固定攻击的文章，我遇到的最流行的解决方案是在用户登录时更改 SessionID，并使用 GUID 创建额外的 cookie 来验证用户“属于”SessionID .
我的问题是:仅仅删除 SessionID cookie (ASP.NET_SessionID) 来确保生成新的 SessionID 还不够吗？ 在 MVC 5 中，当用户登录时，会创建一个额外的加密用户声明 cookie (AspNet.ApplicationCookie)，Identity 使用该 cookie 在每次请求时对用户进行身份验证。额外的“GUID cookie”似乎没有必要。
我最初是一名 .NET 桌面应用程序开发人员，正在编写我的第一个 MVC 应用程序，学习曲线有点陡峭……尽管令人耳目一新，令人愉快。
感谢您的帮助。
最佳答案
让我尝试通过桌面应用程序和 Web 应用程序(均在 .Net 中)之间的比较来解释问题和解决方案
当您启动桌面应用程序时，应用程序首先显示的是登录屏幕，之后您将被授予对 UI 的访问权限。现在，每次启动应用程序的 exe 时，它都会将“RunID”写入文本文件并显示登录屏幕。 RunID 是如何跟踪/关联应用程序的其余使用情况。
假设该文件位于 C:\RunID.txt。
攻击者(黑客)可以在 Machine1 上启动 exe(无需登录)，并将 C:\RunID.txt 的内容复制到 Machine2。现在，只要您登录 Machine1，Machine1 的 RunID token 也将在 Machine2 上工作，这称为 session 固定。
解决此问题的理想方法是放弃预身份验证 token ，并颁发新的后身份验证 token 。因此，您将在身份验证后获得一个新的 token (或者在您的情况下，一个额外的 GUID)，该 token 在 Machine2 上不存在，因此除了 RunID 随机 token ( session ID)之外还提供一定程度的安全性
如果您想进一步解释，请告诉我，但这就是为什么即使在 MVC 中，您也应该放弃以前的 session 并在身份验证后创建一个新 session 以避免 session 固定，作为补偿控制，您可以添加一个GUID cookie 也与 session ID cookie 相对应。
关于asp.net-mvc - MVC 5 中的 session 固定攻击仍然是一个问题吗，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/35071577/