HttpContext.Current对象i .NET背后有哪些缺陷？
我热衷于扩展身份验证服务，并希望了解HttpContext.Current的安全透视图。假设您有一个身份验证服务网站/ wcf等(在适用http的情况下)。HttpContext.Current用于在Item数组中存储会话和其他信息，无需在整个会话中传递凭据。
HttpContext有多安全?它能被滥用和利用安全漏洞吗？有很多帖子和博客谈论“不要将会话或System.Web放入您的业务层”。有些只是说“不要让用户知道您的业务层”。用户会知道什么，“业务层”的边界在哪里？也就是说，业务层仅仅是网站的基础。
那些人所预测的危险在哪里，想要破坏身份验证的用户可以做些什么？是否有“太容易”来开发错误，使系统的行为出乎意料，或给予更多的访问权，然后被提及？
回答 2
Security用户
发布于 2011-11-12 18:11:37
“不要将会话或System.Web放入您的业务层”
造成这种情况的主要原因是它完全使单元测试成为一场噩梦。您的业务层应该是完全独立于您的web层，您应该能够采取该BLL，并将其放入桌面应用程序，并让它运行良好。
作为HttpContext.Current是对象(请求、响应、会话等)的集合。而且他们每个人都有自己的源(请求头、响应缓冲区、绑定到ASP.NET会话ID cookie的会话)，对于HttpContext没有一个通用的答案。
然而，会话确实存在一些固有的问题，劫持和会话固定是其中之一，主要是由于无法在登录上旋转会话ID，Micrsoft拒绝修复这个问题，您将需要围绕这个问题实现安全性(例如，登录时对会话ID的Webforms加密是我简要研究过的一个例子(您可能希望对其进行更多的研究)，或者在我们使用时，一个与您的会话绑定的身份验证cookie仅在HTTPS上运行并在需要时旋转)。
至于像用户和标识这样的项目，它们依赖于您的身份验证方法，通常由Webforms处理，但是如果您再次使用自定义方法，则安全性取决于您使用标准实践。
Security用户
发布于 2011-11-12 18:55:18
因此，严格地说，HttpContext.Currenty在技术上不是一个安全边界，因为它只是一个线程边界。如果(服务器端)代码的位置正确(或者可能是错误的)，我可以闯入其他人的会话。
正如@StrangeWill所指出的，关于不进行会话或与业务层可见的任何相关内容，它更像是一个架构决策，而不是一个安全决策。
https://security.stackexchange.com/questions/8851
复制相似问题
腾讯云开发者
