问题描述
这是挑战：
服务/业务层有一个REST（JSON）接口。
有两种可以调用API的客户端：webapp，它运行在浏览器和移动应用程序（Android）中。他们都是公开的。使用授权（！）webapp或授权（！）移动应用程序的每个人都应该有权访问这些资源。应禁止所有未经授权的客户端（例如脚本）。
The service-/business layer has a REST (JSON) interface.There are two kinds of clients which can call the API: The webapp, which is running in a browser and a mobile-app (Android). Both of them are public. Everyone who uses the authorized (!) webapp or the authorized (!) mobile-app should have access to the resources. All unauthorized clients (scripts, for instance) should be prohibited.
注意：有多少用户或哪些用户可以访问服务层 - >客户端公钥没有限制证书可能无法使用。只有客户端软件必须经过授权。
Note: There are no limitations how many or which users have access to the service layer -> client public key certificates probably can't be used. Only the the client software has to be authorized.
在我看来，唯一的解决方案是默默无闻。
In my opinion the only one solution is "by obscurity".
- 从服务器加载一个随机的JS函数（让我们称之为挑战）浏览器（或应用程序）以特定方式指纹浏览器（浏览器漏洞？），计算结果并将结果发送回每次REST-API调用。
您有任何进一步的想法或建议吗？
Do you have any further ideas or suggestions?
提前谢谢你&抱歉我的英文不好
Thank you in advance & sorry for my bad english
我的问题与用户身份验证和/或授权无关但是客户端软件身份验证+授权。
My question has nothing to do with user authentification and/or authorization but client-software authentification + authorization.
我的问题的背景是，我自己的应用程序有一个RESTful后端（ android + web）我不希望有人在它上面创建自己的客户端软件。之所以这样，是因为它是一个商业网站/应用程序，提供了一些收集费用非常高的数据。我想推广网站和移动应用，而不是RESTapi（或某些第三方竞争对手）。
The background of my question is, that there is a RESTful back-end for my own applications (android + web) and I don't want that someone creates his own client-software on top of it. The reason for this is because it's a commercial website/application which provides some data which was quite expencive to collect. I'd like to promote the website and the mobile-app and not the RESTapi (or some third-party competitor).
推荐答案
不幸的是，我的回答是你应该永远不要相信客户端应用程序。
Unfortunately, my response is that you should simply never trust the client application(s).
虽然有各种方法可以与您分发的客户建立信任关系，所有这些都可以被黑客攻击，破解或绕过。永远不要相信来自服务器外部的任何数据。永远。永远不要依赖于来自客户端或主要Web浏览器的连接。所有事情都可以通过足够的时间和精力进行欺骗。
While there are various ways to create a trust relationship with the client you have distributed, all of them can be hacked, cracked, or bypassed. Never trust any data coming from outside your server. Ever. Never rely on connections to be coming from your client or a major web browser. Everything can be spoofed with enough time and effort.
从游戏这样的事情中可以很容易地看到一些类似行业这类问题的好例子，即使是通过例程来检查记忆黑客和其他方法，最终甚至像魔兽世界那样拥有巨额预算的服务经常会看到他们客户端的黑客出现或者能够发送普通客户端不会发送命令的彻底的客户端模拟器。依靠您的客户端软件保持安全，只有将适当的数据发送到您的服务器才是灾难。如果是重要的事情，请始终验证服务器端。始终正确地转义/参数化数据。使用白名单模型，并且最好在适当的情况下使用基于用户输入的符号表查找而不是用户数据本身。等等。客户端验证应该只被视为帮助用户，而不是安全的东西。
Some good examples of issues like this in the industry are easily seen from things like gaming, where even with routines to check for memory hacks and other approaches, eventually even services with huge budgets like World of Warcraft often see either hacks of their client appear or outright client emulators capable of sending commands the normal client would not. Relying on your client software to remain secure and only ever send proper data to your server is a recipe for disaster. Always validate server side if it is for something important. Always properly escape/parameterize data. Use whitelist models, and preferably use symbol table lookups based on user input instead of user data itself where appropriate. Etc. Client side validation should only ever be seen as helping the user, not as something secure.
如果你只是为了足够好那么你可能会有一些帮助减少看到这种情况发生的可能性的选项，例如您提出的通过默默无闻解决方案的安全性，但您不应该依赖就不会发生这种情况，即便如此。
If you are simply going for "good enough" then you may have some options to help reduce the likelihood of seeing this happen, such as a security through obscurity solution like you proposed, but you should never rely on it not happening, even then.
一个解决方案是基本上不包括客户端内客户端的主要功能，而是在运行时从服务器（javascript / etc）发送它，使用不同的指纹每次将逻辑包发送到客户端时，可能会使用一系列不同的逻辑例程，随机选择一个。然后，您可以超时打包，跟踪哪个用户访问了哪个包，并让包返回telemetrics，您还可以使用它来帮助维护安全性。返回的逻辑与使用指纹发送的内容之间的任何不匹配都可以立即被假定为欺骗或黑客尝试。然而，归根结底，所有这些仍然可以被打败（像这样的相对基本的例子可以被确定的人轻易打败，特别是如果你没有运行时内存安全性）。
One solution is to basically not include the major functionality of the client within the client, but instead send it from the server (javascript/etc) at runtime, with a different fingerprint for each time you send your logic package to the client, possibly with a range of different logic routines, with one randomly picked. You can then timeout the packages, track which user accessed which package, and have the package return telemetrics which you also use to help maintain security. Any mismatch between returned logic and what was sent with the fingerprint can immediately be assumed to be a spoof or hack attempt. Ultimately, however, all of this can still be beaten (a relatively rudimentary example like this can be beaten rather easily by someone determined, especially if you don't have runtime memory security).
有多种方法可以处理中间人（MITM）攻击，有人试图拦截数据，但没有一种方法可以完全解释受损端点。
There are a number of ways to deal with man in the middle (MITM) attacks, where someone is trying to intercept data, but none of them can fully account for a compromised endpoint.
这篇关于REST - 如何限制未授权客户端软件的访问的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！