ASP.NET Forms身份验证和持久身份验证Cookie安全性

当我们在任何ASP.NET框架(ASP.NET MVC,Web窗体等)中使用ASP.NET Forms Authentication时,我们会在客户端的浏览器中保留身份验证cookie.作为最佳实践,我们将cookie设置为HttpOnly并且安全.我们还通过SSL进行所有交易.无论我们使用何种机制来验证用户(OAuth,ASP.NET成员资格提供程序等),我们仍然需要保持身份验证以获得更好的用户体验.

有了所有这些,我假设有人仍然可以从客户端浏览器中获取cookie并使用这些auth cookie值发出请求.服务器无法检测到这种情况,我们会将受保护的数据提供给其他人.

有人认为我想降低这里的风险是每当他/她试图采取一些严肃的行动(例如更改电子邮件地址,访问个人资料信息等)时询问客户的密码,但这并不能解决任何东西,对客户来说都很烦人.

对于这类问题,您有任何积极关注的方法吗？或者在客户端浏览器中保持身份验证的最佳方法是什么？

解决方法

你正在做一切正确的事情.

如果您正在使用成员资格提供程序,那么cookie将仅标记为HTTP(如您所述),因此无法通过客户端脚本(如恶意的XSS)访问该cookie.

如果您已将cookie标记为安全,那么我假设您已将表单身份验证中的“RequireSSL”标志设置为true.通过这样做,cookie不会被发送到任何不通过HTTPS发送到服务器的请求,所以即使你不小心插入HTTP请求(浏览器应该警告用户无论如何嵌入的内容一个HTTPS页面),不会发送cookie.

你可以做的唯一的另一件事 – 这并不能提供你所拥有的很多防御,但这是一个很好的做法 – 也是使用HSTS.我在OWASP Top 10 for .NET developers part 9: Insufficient Transport Layer Protection中讨论这个问题,作为确保通过安全通道继续发送请求的另一种方法.

如果没有对会员提供商进行一些严肃的重新设计,那么你可以做的事情真的不多.您可以将会话绑定到IP,如果它发生更改则不接受请求,但这可能会导致问题(即IP会更改并且不会保护您免受同一地址上的多个人的攻击).您还可以创建浏览器的指纹(即在请求标头中发送的所有内容)并确保后续请求匹配,但我们在此处详细介绍.

但最终,安全性应根据其所保护的资产的价值和恶意活动的可能性进行调整.你没有说你正在保护什么,但如果它是一个金融系统,你会比在博客上使用简单的评论引擎更长.

总而言之,看起来你做得很好,只考虑你在所保护的价值背景下实施的措施的适当性.哦 – 如果您使用sql成员资格提供程序进行凭据存储,请确保您阅读Our password hashing has no clothes然后停止这样做！