JSON RPC over TLS是否足够安全？

Question

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

Answer 1

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

清单

以下是需要安全性的清单，以及如何解决这些问题：

• 第三方无法窃听您的通讯。 HTTPS提供此功能。
• 第三方不能篡改您的通讯。 HTTPS也提供此功能。
• 客户端可以验证服务器。 HTTPS提供此（*）。
• 服务器可以验证客户端。

客户端身份验证

有很多方法可以验证客户端。以下是一些问题：

• 使用API​​密钥计算请求的HMAC，并在请求中包含HMAC作为标题。 （**）最安全，但设置更复杂。关键优势在于，如果您的服务器遭到入侵，API密钥将不会暴露。
• 在请求中包含API密钥本身。设置更简单，可能具有足够的安全性，具体取决于您的要求。
• ...

---

（*）：只要客户端库可以。 HTTPS要求您使用验证您的站点对应于域名的证书。不幸的是，许多HTTPS库默认不对此进行验证 （**）：您还应该使用随机数来防止重放攻击。

Answer 2

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

盐还可以防止成功的窃听者故意改变信息。

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

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

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

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