如何保障COTS REST API仅用于批准的客户端应用程序的前提服务器？

Question

目标:防止未经授权的“克隆”应用程序使用基于REST的解决方案，即客户管理自己的服务器和服务，而不是供应商这样做(数据库、资源和身份)。换句话说:前提服务器而不是基于云的解决方案。

除了我们自己的应用程序之外，我的公司希望能够只授权一些第三方来创建能够使用我们的API的应用程序，而不仅仅是任何人。因此，我们可能会有一些程序，第三方将提交他们的应用程序给我们签署，并添加到某种“白名单”(任何形式，最终采取)。因此问题。)。

(为什么没有云？一些国家和行业受到更严格的监管，对于某些类别的敏感操作数据来说，云服务器或场外服务器不是一种选择。如果这还不够好的原因，那么请考虑这是一个思维实验)。

这个问题是这个几乎相同的问题上的一个变化，但是有一个附加的约束，即软件供应商不拥有或管理服务器。

我与Approov的制造商CodeBlue没有任何联系，但他们确实发布了一个不错的解释，说明了确保web应用和移动应用程序REST安全的典型过程。这里有一个指向第3部分第2部分的链接，它涵盖了一些关键点，例如中介服务器和授权客户端的认证过程，以及对公共客户端(即:移动应用程序)保持共享机密的技术。

https://www.approov.io/blog/mobile-api-security-techniques-part-2.html

上面这篇文章从CodeBlue描述的解决方案对于基于云或供应商控制的环境来说听起来很不错。然而，当客户不仅可以物理访问客户端，而且还可以访问服务器时，我一直在努力寻找防止克隆应用程序的方法。单独配置可能会启用未经授权的应用程序，如果不起作用，应用程序本身可能会被修改。

当然，这里有一个法律安全网(许可协议、服务条款)，但是，如果不是直接阻止它，是否有什么代码上的明智之举可以阻止它呢？

我知道--并在追求--各种技术来混淆解决方案(比如传播周围的秘密，防止逆向工程)和客户认证，但在我的所有模型中，到目前为止，恶意客户(或代理)可能会欺骗REST，使其相信请求是由授权的客户端提出的。我知道我在这里处于某种军备竞赛中，所以我向社区寻求这方面的想法，因为我在过去一周研究的所有方法都依赖于拥有服务器的供应商。

Answer 1

你似乎有一个非常具体的要求。

从技术上讲，这是不可能的，但人们无论如何都会实现解决方案。因为你只需要让它变得更难，而不是不可能。

在您的例子中，我会混淆API并向拥有嵌入式ids的授权开发人员发布客户端库。可能您可以简单地用共享的秘密加密数据。或者使用自定义二进制序列化。

这样，你就很难创建自己的客户端，如果你在未经授权的应用程序中发现客户端，就可以计算出是谁泄露的。

对服务器进行频繁更新，从而调整API，将给未经授权的应用程序开发人员带来额外的负担。

当然，您的客户可能选择不安装更新。但他们最终会想要与之配套的功能。

Answer 2

我的理解是，您有一个已部署的解决方案，您的组织认为它是安全的，因为它是一个封闭的API和一个封闭的应用程序。因此，我的第一个想法是强调，您已经没有办法跟踪访问您的API的应用程序--没有私有API这样的东西。从监听流量或反向工程应用程序中反向工程API通常是很简单的事情。由于您的客户同时拥有服务器端和应用程序，因此他们必须已经能够访问实现这一目标所需的所有代码。API-关键，代码混淆，固定连接-这些通常是相当容易规避的经验丰富的专业人士。(正如您经常在Approov博客上提到的那样。)

尽管如此，我相信正常的Approov流可以支持您的用例，但是使用非对称密钥来签署用于在Approov云服务和后端之间传输信任的JWT。使用非对称密钥允许后端验证令牌签名，而无需访问用于签名令牌的私钥。这样，后端将只为注册应用程序的请求提供服务。当然，这个解决方案不会阻止您的客户完全克隆您的后端服务。正如你所建议的，但正如我所说，你的现有解决方案有这个问题。(您可以联系Approov，看看他们如何支持这一流程。)

免责声明:我在Approov工作