有了所有这些,我假设有人仍然可以从客户端浏览器中获取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然后停止这样做！
