4

我打算让 PHP Web 服务接受 JSON-RPC over TLS (HTTPS)。每个客户端都有一个 API 密钥，我将用于识别目的。是否足够安全，是否有 JSON-RPC 安全特定标准？

4

2 回答 2

5

这是做事的好方法。以下是您的安全方案中的要求和组件的概述：

清单

以下是需要什么安全性以及如何解决它的清单：

  • 第三方无法窃听您的通信。HTTPS 提供了这一点。
  • 第三方无法篡改您的通信。HTTPS 也提供了这一点。
  • 客户端可以对服务器进行身份验证。HTTPS 提供此 (*)。
  • 服务器可以对客户端进行身份验证。

客户端认证

有很多方法可以验证客户端。这里有几个例子：

  • 使用 API 密钥计算请求的 HMAC 并将 HMAC 作为请求头包含在请求中。(**) 最安全，但设置起来更复杂。关键优势是，如果您的服务器受到威胁，API 密钥将不会暴露。
  • 在请求中包含 API 密钥本身。更容易设置，根据您的要求可能足够安全。
  • ...

(*)：只要客户端库可以。HTTPS 要求您使用证书来验证您的站点是否与域名相对应。不幸的是，许多 HTTPS 库默认情况下不验证这一点。
(**)：您还应该使用 nonce 来防止重放攻击。

于 2012-12-28T13:18:56.043 回答
1

您可以使用秘密盐签署请求（+ 选择的哈希算法，MD5 会很好），因为这样窃听者无法获得“API 密钥”并伪造他自己的请求。使用很长的盐。

盐还起到防止成功窃听者故意更改消息的作用。

中间怎么会有男人？除非您为每个客户端颁发白名单证书，否则 TLS(SSL) 对中间人攻击的安全性并不高。例如，中间的服务器（攻击者）获得了有效的证书，或者客户端应用程序没有检查各种证书的有效性设置（到期日期等）。如果不在您的控制之下，您的 RPC 服务器的客户端很可能会在不进行任何类型的安全检查的情况下进行连接。这是一个普遍的问题。窃听通常意味着访问您（或您的客户）的网络，因此这可能意味着中毒的 DNS 流量重定向到流氓服务器。

您或您的客户端的网络连接是否足够安全以排除 DNS 中毒的可能性，或者您的客户端正在检查证书的有效性，或者您强制客户端使用列入白名单的 SSL 证书，这些只有您可以影响或决定。

您可能还希望通过为每个请求分配一个唯一编号来防止重放攻击（如果这些 API 调用仅用于读取，则可能会过度杀伤）以拒绝重复请求。

您提到的 API 密钥通常在涉及浏览器端 JavaScript 客户端来跟踪使用情况时使用。API 密钥在被盗时会重新发布，以识别和禁用未经授权的应用程序（并且可能会自动列出欺诈性域名以进行进一步的 [诉讼] 行动）。

于 2012-12-28T12:53:29.017 回答