当我们在任何 ASP.NET 框架（ASP.NET MVC、Web 窗体等）中使用 ASP.NET 表单身份验证时，我们会将身份验证 cookie 持久保存在客户端的浏览器中。作为最佳实践，我们将 cookie 设置为 HttpOnly 且安全。我们还通过 SSL 进行所有交易。无论我们使用什么样的机制来验证用户（OAuth、ASP.NET Membership Provider 等），我们仍然需要持久化验证以获得更好的用户体验。
有了所有这些，我假设有人仍然可以从客户端浏览器中获取 cookie 并使用这些 auth cookie 值发出请求。服务器无法检测到这一点，我们会将受保护的数据提供给其他人。
一个想法是，我想降低这里的风险，每次他/她尝试采取一些严肃的行动（例如更改电子邮件地址，访问个人资料信息等）时询问客户的密码，但这并不能解决任何事情，对客户来说都可能很烦人。
对于此类问题，您是否有任何积极遵循的方法？或者在客户端浏览器中保持身份验证的最佳方法是什么？
你几乎做的一切都是正确的。
如果您使用的是会员提供程序，那么 cookie 将被标记为仅 HTTP（如您所说），因此无法通过客户端脚本（例如恶意 XSS）访问它。
如果您已将 cookie 标记为安全，那么我假设您已将表单身份验证上的“RequireSSL”标志设置为 true。通过这样做，cookie 不会在任何不通过 HTTPS 发出的请求中发送到服务器，因此即使您不小心插入了 HTTP 请求（如果它的内容嵌入在浏览器上，浏览器应该警告用户无论如何HTTPS 页面），cookie 将不会被发送。
您唯一可以做的另一件事——除了你所拥有的东西之外，这并不能提供太多的防御，但这是一个很好的做法——也是使用 HSTS。我在OWASP Top 10 for .NET 开发人员第 9 部分中谈到了这一点：传输层保护不足作为确保请求继续通过安全通道发送的附加方法。
除了对会员提供商进行一些认真的重新设计之外，您真的无能为力。您可以将会话绑定到一个 IP，并且如果它发生变化则不接受请求，但这可能会导致问题（即 IP 发生变化并且不能保护您免受同一地址上的多个人的影响）。您还可以创建浏览器的指纹（即在请求标头中发送的所有内容）并确保后续请求匹配，但我们将在这里进行非常详细的介绍。
但归根结底，安全性应该根据所保护资产的价值和恶意活动的可能性进行调整。你不会说你保护的是什么，但如果它是一个金融系统，你会比博客上的一个简单的评论引擎更努力。
总而言之，看起来您做得很好，只需考虑您在保护的价值背景下实施的措施的适当性。哦 - 如果您使用 SQL 成员资格提供程序进行凭证存储，请确保您阅读了我们的密码散列没有衣服然后停止这样做！
加上你所做的一切，并考虑到我额外建议的这个问题，将更多关于用户的信息与身份验证 cookie 一起保存在服务器上，所以如果有人窃取 cookie 并尝试使用它，也是必须满足客户端的所有其他特征才能使用它。
我保留并检查的其他一些信息与身份验证 cookie 是否相同。
我知道有人会说所有可以被黑客克隆的东西——如果黑客可以拿走 cookie，为什么不能拿走其余的。好吧，在这种情况下，没有什么是 100% 保证的，如果有人可以获取所有这些信息实际上可以拥有的信息以及密码它自己和登录 - 至少你让它更安全一点。
您已经在使用 HTTPS 并加密 cookie，这是相当安全的。
如果您仍然担心，我建议在服务器上存储有关用户会话的其他信息（IP 地址、用户代理等），并根据会话期间提供的信息进行验证。
如果用户更改了他们的电子邮件地址，您可以向原始电子邮件地址发送一个撤销链接，因此如果该更改未经授权，则真正的所有者会收到有关更改的警报。