防止 ASP.Net MVC 中的 Cookie 重放攻击
我的任务是实现本文中的第 4 点：http://support.microsoft.com/kb/900111
这涉及使用会员资格提供程序在用户登录和退出时向服务器端记录添加注释，然后确认当使用 cookie 进行身份验证时，用户尚未退出。这对我来说非常有意义。开始崩溃的地方是我们当前不使用会员资格提供程序，因此我似乎面临重新实现所有身份验证代码以使用会员资格提供程序。目前，我们在控制器中检查身份验证，并在知道用户存在后调用 FormsAuthentication.SetAuthCookie()。强迫会员提供商加入需要做很多工作。
所有这些工作真的有必要吗？我可以将自己的 cookie 值键值存储滚动到已登录的用户，并确保在用户点击注销按钮时清除此值吗？如果这看起来不安全，是否有一种方法可以实现最小的会员资格提供程序，以便在不将所有身份验证代码移交给它的情况下进行这些检查？
我想我的主要问题是，我们很久以前就决定会员资格提供商模型不适合我们用于锁定和解锁帐户的模型，因此选择不使用它。现在我们发现 MS 的建议特别提到了会员提供商，并且由于这是安全性的，我需要确保不按照他们的建议使用它不会造成麻烦。
I have been tasked with implementing point 4 in this article: http://support.microsoft.com/kb/900111
This involves using the Membership provider to add a comment to users server side records when they log in and out, and then confirming that when a cookie is used to authenticate, that the user hasn't logged out. This makes perfect sense to me. Where this starts to fall apart is that we do not currently use a membership provider, and so it seems like I face reimplementing all our authentication code to use a membership provider. We currently check authentication in a controller, and make a call to FormsAuthentication.SetAuthCookie() once we know the user exists. It would be a lot of work to force a membership provider in.
Is all this work really neccesary. Can I roll my own key value store of cookie values to logged in users and just make sure I clear this when a user hits the logout button. If this seems unsafe is there a way of implementing a minimal Membership provider in order to make these checks without handing off all authentication code to it?
I guess my main problem here is that we decided a long time ago that the membership provider model doesnt fit with the model we use for locking and unlocking accounts, and chose not to use it. Now we find that the MS recommendations specifically mention a membership provider, and as this is security I need to be sure that not using it as they recommend isn't going to cause troubles.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的，你可以这样做。会员提供商保留一小组有关用户的数据（用户名、电子邮件、密码、上次登录、丢失密码问题、丢失密码答案等）。
如果您不想改造会员提供商，我会采取您提到的方法。无论信息是写入 aspnet_Users 表的注释字段还是您自己的表中的位字段，都应该没有任何区别。
您可能还需要考虑将接口设置为您的会员/身份验证代码。然后，您可以在更方便的时候将当前代码替换为会员提供程序实现。
Yes, you can do this. The Membership Provider keeps a small set of data about the user (username, email, password, last login, lost password question, lost password answer, etc).
If you don't want to retro fit a membership provider I would take the approach you mentioned. Whether the information is written to the comment field of the aspnet_Users table or a bit field in your own table, it shouldn't make any difference.
You also might want to consider putting an interface your Membership/Authentication code. Then you could swap your current code to a Membership Provider implementation when it's more convenient.
我发现 MembershipProvider 非常有帮助。它允许我作为开发人员针对本地用户数据库使用 SQLMembershipProvider，然后当我将其转移到生产环境时，只需使用 ActiveDirectoryMembershipProvider，并且我不必更改一行代码（除了我的 web.config 中的代码）文件）。
使用他们的 CustomMembershipProvider，您可以重载任何身份验证方法，并在这些方法中执行您想要的任何其他检查。
如果您决定跳至 MembershipProvider 计划，我认为您不会后悔。短期内可能会很痛苦，但从长远来看，我认为你会看到它得到回报。由于您已经在控制器中编写了很多身份验证代码，也许将其融入 MembershipProvider 使用它的方式中并不难？
MP 是最好让它做它最擅长的事情的时候之一。如果你尝试在这里只使用它的一部分，在那里使用它的一部分，虽然可能，但会在以后引起一些麻烦。它知道自己应该做什么，并且规避它虽然可能，但需要额外的工作，而这些工作可能最终是不必要的。
I've found the MembershipProvider to be very helpful. It allows me as a developer to use the SQLMembershipProvider against a local database of users, and then when I move it to production, to simply use an ActiveDirectoryMembershipProvider and I don't have to change a line of code (except in my web.config file).
Using their CustomMembershipProvider, you can overload any of the authentication methods and do whatever other checks you want inside of those methods.
If you decide to jump to the MembershipProvider scheme, I don't think you'll regret it. It may be painful in the short term, but in the long run, I think you'll see it paid off. Since you've already got a lot of your authentication code written in your controller, perhaps it won't be that hard to meld it into the way MembershipProvider uses it?
MP is one of those times when its best to let it do what it does best. If you try to use just part of it here and part of it there, while possible, will cause some headaches down the road. It knows what it is supposed to do and circumventing it, while possible, will require extra work that may turn out to be unnecessary.