避免 ASP.NET 中的会话劫持
我最近在此处阅读了一篇关于使 ASP.NET 会话更安全的文章，并且乍一看它确实很有用。
以前，我一直将用户的 IP 地址存储在会话中，然后确保在每个后续请求中请求的 IP 与存储的 IP 相同。
本文中的代码还通过检查 IP 地址来保护会话，但它存储包含用户 IP 的哈希消息身份验证代码作为会话 cookie 的一部分。它为每个请求创建两次哈希 MAC，我想这会减慢速度。
我已经可以在他们的代码中看到一个潜在的缺陷：如果你以某种方式获得用于生成 MAC 的密钥，那么你就可以使用你自己的 IP 生成一个有效的 MAC - 你甚至不必伪造 IP会议于 开始。
这似乎是对一个简单问题的过于复杂的解决方案，它不仅会产生更大的开销，而且比简单的方法更容易受到攻击 - 除非我完全没有抓住重点。
那么，为什么这种方法比我一直使用的更简单的方法更安全呢？
顺便说一句，作者还指出，您不应该在比较中使用整个 IP 地址，因为某些用户的 IP 如果位于代理后面，就会更改每个请求。如果您检查X_FORWARDED_FOR，情况仍然如此吗？
谢谢！
I recently read an article on making ASP.NET sessions more secure here and at first it seems really useful.
Previously I had been storing the user's IP address in the session, then making sure in every subsequent request that the requesting IP was equal to the stored IP.
The code in the article also protects the session by checking the IP address, except it stores a hashed message authentication code containing the user's IP as part of the session cookie. It creates a hashed MAC twice every request, which I imagine would slow things down a little.
I can already see a potential flaw in their code: if you were to somehow get a hold of the key used to generate the MAC, you could then generate a valid MAC with your own IP - you wouldn't even have to fake the IP the session was started on.
It seems like an overly-complex solution to a simple problem which not only incurs a larger overhead but also is more susceptible to attack than the trivial method - unless I'm completely missing the point.
So, why would this approach be any more secure than the more simple approach that I had been using?
As a slight aside, the author also states that you shouldn't use the whole IP address in the comparison, as some user's IPs change every request if they are behind a proxy. Is this still the case if you check X_FORWARDED_FOR?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
请参阅这篇文章：防止会话劫持的最佳方法是什么？ 。
基本上，您应该在登录页面和任何其他“敏感区域”上使用 HTTPS
See this post: What is the best way to prevent session hijacking?
Basically, you should use HTTPS on your login page and any other "sensitive areas".