带有纯 JavaScript 前端的 webapi 后端，安全性答案

【问题标题】：webapi backend with pure javascript frontend, security带有纯 JavaScript 前端的 webapi 后端，安全性
【发布时间】：2014-08-07 12:49:40
【问题描述】：

所以现在我非常赞同拥有纯 html+js 前端的想法，其中所有处理都发生在客户端浏览器上，后端提供 JSON/xml/其他格式的所有数据等等。

这是两难境地，

对于身份验证，我使用的是 OAuth2 Bearer 令牌，该令牌在用户使用用户名和密码进行身份验证时生成（例如在登录阶段）。

向此 WebAPI 发出请求的客户端应用程序（即前端 Web 服务器或移动应用程序）具有额外的安全性。当它发出初始请求时，它会传递“client_id”和“client_secret”以确保客户端应用程序有权向后端服务器发出此请求。

在传统的 .NET 方式中，我会将加密的客户端 ID 和密钥存储在 web.config 中，我的 C#（或 VB.NET）代码将检索它并通过 SSL 将其发送到服务器。因此，client_id 和 client_secret 不会在呈现的 HTML（例如）中暴露给客户端浏览器。

在纯 javascript 环境中，如何保护我的 client_id 和 client_secret（或任何其他敏感数据）？

谢谢

【问题讨论】：

1 和 2 应该是单独的问题，而 #3 太宽泛了。是的，对于客户端应用程序，您需要了解十亿件事。

标签： javascript angularjs security asp.net-web-api oauth

【解决方案1】：

我不认为你可以保护你的“秘密”。

HTML5/JS 代码是纯文本，任何有文本编辑器的人都可以看到。人们通常尝试做的是使用 javascript 压缩器/压缩器来混淆他们的代码；请参阅here 进行很好的讨论。这种做法称为Security through Obscurity。但请注意，混淆不是安全。只要付出时间和精力，一个坚定的“黑客”最终会找到你的秘密。您可以采取的阻止、延迟和挫败此类攻击的另一个步骤是在代码、不同模块等中传播您的秘密信息。话虽如此，您需要在某个时候编写代码来组装它们，所以再说一次，没有真正的安全性。

我有一个类似的问题，因为我想在服务器上使用“共享密钥”，这样我就可以对我的客户端请求进行哈希处理，这样它们就可以防篡改，并且在附件不知道共享密钥的情况下无法重新创建它们。不幸的是，我不得不放弃这个想法，因为我意识到我不能保持足够的秘密。

【讨论】：

那你是怎么做的呢？然后，您是否接受来自任何客户端的请求而没有任何 client_id 和 client_secret？如果是这样，它不会对来自任何服务器的随机服务请求产生影响吗？
我几乎已经放弃了拥有“秘密”的想法，因为似乎不可能保证 100% 的安全。客户端实现还处于开发的早期阶段，所以现在可以说，还有更大的鱼要炒。一种可能的解决方案可能是使用客户端证书。我在使用这些方面没有任何经验，但他们依靠 PKI 来加密/解密文本。您可能需要进一步调查。就我而言，客户端将是一个移动应用程序，因此为每个客户端拥有一个客户端证书是一场维护噩梦。
另外，我的服务正在使用令牌身份验证，因此只有经过身份验证的客户端才能访问数据。问题是我将令牌保存在本地存储中，因此理论上，用户手机上的某些恶意应用程序可以检测到令牌并使用它来发出虚假请求。我正在考虑在将令牌保存到本地存储之前编写代码来“加密”令牌，但同样，密钥将在我的 javascript 文本中，所以除了需要额外的努力之外，这样做没有任何意义它。
当您说只有“经过身份验证的客户端可以访问”时。不是说你的 if client_id/client_secret 存储在 js 中，那么任何人都可以拿起 fiddler 并开始向你的 webapi 服务器发起请求？
对于要“认证”的客户端，需要向服务器提供用户名和密码（始终通过 HTTPS），服务器将检查其凭据，如果有效，则返回一个令牌。对于后续请求，客户端只需提供令牌。正如我在上一条评论中提到的，这个令牌需要存储在客户端的某个地方。如果客户端上运行的恶意代码能够获取该令牌，那么是的，他们可以开始向我的服务器发出请求。我会尝试以某种方式混淆令牌，但最终，一个坚定的黑客总能找到解决这个问题的方法。