在客户端存储身份验证令牌的缺点？

信息安全 验证 客户端 阿贾克斯 asp.net-mvc
2021-09-03 05:59:56

我正在开发一个 ASP.NET MVC Web 应用程序，它从后面的 API 获取数据。因此，身份验证目前是通过 ASP.NET 表单身份验证完成的，这意味着客户端将电子邮件和密码发送到网站，网站将该数据传输到 API，该 API 返回一个身份验证令牌，该身份验证令牌存储在 ASP.NET 会话中。之后，在客户端上设置身份验证 cookie。

没关系并且安全（据我目前的知识），没有凭据或令牌存储在客户端。

作为一个缺点，每个 AJAX 请求都必须通过网站进行路由。结果，我有大量的 ASP.NET MVC 操作，它们除了将请求转发到 API 并返回从那里返回的结果之外什么都不做。

这可能是未来的瓶颈，因为网站基础设施必须以与 api 基础设施相同的方式进行扩展。现在我正在寻找一种解决方案来通过网站删除这些冗余调用并直接从客户端（通过 AJAX）访问 API。

这需要来自客户端的 API 身份验证。从技术上讲，如果我将身份验证令牌存储在 LocalStorage 中（不支持旧浏览器），那将不是问题。

但这种方法有多安全？JSONP 旁边有哪些窃取令牌的选项（可以通过不包括外部脚本来防止，对吗？）？

1个回答

由于您将通过 Ajax 调用 API 服务器（意味着相同的页面 - 和相同的 JavaScript 上下文 - 将保持不变）我建议在主服务器中创建一个短暂的令牌，让浏览器请求一次，然后使用它与 API 服务器进行身份验证，直到页面关闭（或令牌过期，以先发生者为准）。下次用户访问该页面时，生成一个新令牌。

这样，对主服务器的调用将不常见（无论如何您都无法避免它们，因为每次用户注销或清除 cookie 时，他都必须再次通过主站点进行身份验证），并且您避免了麻烦不得不保护另一条数据。

至于本地存储攻击向量，我相信理论上它们与 cookie 相关的攻击向量大致相同——XSS、对机器的物理访问等——因为它受制于同源策略（至少是那些由 SSL 创建的策略）受保护的页面），但与 cookie 不同，它不支持通过路径限制可见性（即域中的所有页面都可以访问来自任何其他页面的数据）。然而，在实践中，它的实现方式可能存在不一致，以及其他安全漏洞，所以我不会相信它，除非我非常确信它是安全的（以我目前的知识我无法真正断言）。根据此 OWASP 指南，不鼓励在本地存储中存储敏感数据。会话存储是也不是防弹的。

其它你可能感兴趣的问题
上一篇实现两因素身份验证的方法有哪些？ 下一篇如果启用了 WPS 但禁用了 WPS PIN 码，我的路由器是否容易受到攻击？