ASP.NET MVC Web API 身份验证令牌安全问题

Posted 2023-02-19

【中文标题】ASP.NET MVC Web API 身份验证令牌安全问题

【英文标题】：ASP.NET MVC Web API Authentication Token Security Issues

【发布时间】：2016-05-21 23:13:43

【问题描述】：

我正在使用 Web API 开发一个 asp.net mvc 项目。 Web API 将被网站、移动应用程序和第三方使用。现在，在某些 API 上将仅在主页上调用而无需任何登录，而相同的 API 将仅在登录后调用。

现在，考虑到我的网站场景，我从 AngularJs 调用了 API。我们调用了一个 api，它将在 session_start 上生成一个令牌。然后从 NG 中我们调用了一个 mvc 控制器方法，该方法将简单地获取该令牌，然后该令牌将在所有请求的 HTTP-Header 中传递。

在 API 端，我们获取令牌、解密并显示结果。

问题是，当我看到 Google Chrome 的网络选项卡（按 F12）时，我可以很容易地看到 API 调用甚至标头中的令牌。我觉得安全漏洞。对于开放 API，我们考虑了一些过期时间和请求计数。但是有些 API 是敏感的，比如在 DB 中添加数据（POST API，基于作为参数传递的数据），它们也可供访客用户使用。我们不希望有人滥用它并做有害的事情。

在这种情况下，我们如何实现最大的安全性？什么是理想的安全流程？

【问题讨论】：

安全性不依赖于隐藏 API 结构（方法名称、数据格式等），而是只允许授权客户端访问这些 API，这是您的令牌应该做的.换句话说，如果您的令牌在密码学上是可靠的（不能被欺骗或伪造），您的连接受到保护（没有人可以拦截您的令牌）并且您的后端正确地验证和授权您的客户端，那么您应该没问题。

【参考方案1】：

进一步解释 Marco Sandrini 的评论...

安全性不依赖于隐藏 API 结构（方法名称、数据格式等），而是只将这些 API 的访问权限授予授权客户端，这是您的令牌应该做的事情。换句话说，如果您的令牌在密码学上是正确的（不能被欺骗或伪造），您的连接受到保护（没有人可以拦截您的令牌）并且您的后端正确地验证和授权您的客户端，那么您应该没问题。

令牌不应受到重放攻击。服务器应该已经在为后续请求期待令牌的不同排列，而您不应该知道如何通过读取令牌来生成它。

正确的 SSL/TLS 将保护连接的内容不被窥探。如果您的访客用户可以在他们的 Chrome 网络标签中看到其他人的敏感信息，那么您应该担心，因为您的实施策略出了问题。