【问题标题】:ASP.NET MVC Web API Authentication Token Security IssuesASP.NET MVC Web API 身份验证令牌安全问题
【发布时间】: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,这是您的令牌应该做的.换句话说,如果您的令牌在密码学上是可靠的(不能被欺骗或伪造),您的连接受到保护(没有人可以拦截您的令牌)并且您的后端正确地验证和授权您的客户端,那么您应该没问题。

标签: api security asp.net-web-api2 asp.net-mvc-5.2


【解决方案1】:

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

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

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

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

【讨论】:

    猜你喜欢
    • 2019-09-04
    • 2014-10-13
    • 2013-02-12
    • 2015-09-17
    • 2014-04-29
    • 2013-04-14
    • 2017-03-21
    • 2014-06-02
    • 2016-06-09
    相关资源
    最近更新 更多