13

这是挑战：

服务/业务层有一个 REST (JSON) 接口。有两种客户端可以调用 API：在浏览器中运行的 web 应用程序和移动应用程序 (Android)。两者都是公开的。使用授权 (!) webapp 或授权 (!) 移动应用程序的每个人都应该有权访问资源。应禁止所有未经授权的客户端（例如脚本）。

注意：没有限制有多少或哪些用户可以访问服务层 -> 客户端公钥证书可能无法使用。只有客户端软件必须被授权。

在我看来，唯一的解决方案是“默默无闻”。

想法：

  • 从服务器加载一个随机的 JS 函数（我们称之为“挑战”），它在浏览器（或应用程序）中执行，以特定方式对浏览器进行指纹识别（浏览器缺陷？），计算结果并发送结果每次调用 REST-API 时返回。

你有什么进一步的想法或建议吗？

提前谢谢你，对不起我的英语不好

编辑：

我的问题与用户身份验证和/或授权无关，而是与客户端软件身份验证 + 授权有关。

我的问题的背景是，我自己的应用程序（android + web）有一个 RESTful 后端，我不希望有人在它上面创建自己的客户端软件。这样做的原因是因为它是一个商业网站/应用程序，它提供了一些收集起来非常昂贵的数据。我想推广网站和移动应用程序，而不是 RESTapi（或某些第三方竞争对手）。

4

2 回答 2

12

不幸的是，我的回答是你永远不应该信任客户端应用程序。

虽然有多种方法可以与您分发的客户端建立信任关系，但所有这些方法都可能被黑客入侵、破解或绕过。永远不要相信来自服务器外部的任何数据。曾经。永远不要依赖来自您的客户端或主要网络浏览器的连接。只要有足够的时间和精力，一切都可以被欺骗。

行业中此类问题的一些很好的例子很容易从游戏等事物中看到，即使有检查内存黑客和其他方法的例程，最终即使是像魔兽世界这样预算巨大的服务也经常看到他们的客户出现黑客攻击或完全客户端模拟器能够发送普通客户端无法发送的命令。依靠您的客户端软件来保持安全并且只向您的服务器发送正确的数据是灾难的根源。如果是为了重要的事情，请始终验证服务器端。始终正确地转义/参数化数据。使用白名单模型，并在适当的情况下最好使用基于用户输入而不是用户数据本身的符号表查找。等等。客户端验证应该只被视为帮助用户，而不是安全的东西。

如果您只是追求“足够好”，那么您可能有一些选择来帮助减少看到这种情况发生的可能性，例如像您提出的那样通过默默无闻的解决方案实现安全性，但即使那样，您也不应该依赖它不会发生。

一种解决方案是基本上不在客户端中包含客户端的主要功能，而是在运行时从服务器（javascript/etc）发送它，每次将逻辑包发送到客户端时使用不同的指纹，可能使用一系列不同的逻辑例程，其中一个是随机选择的。然后，您可以使包超时，跟踪哪个用户访问了哪个包，并让包返回遥测数据，您也可以使用这些遥测数据来帮助维护安全性。返回的逻辑与指纹发送的内容之间的任何不匹配都可以立即被认为是欺骗或黑客攻击。然而，最终，所有这些仍然可以被打败（像这样一个相对基本的例子可以被确定的人相当容易地打败，特别是如果你没有运行时内存安全性）。

有许多方法可以处理中间人 (MITM) 攻击，其中有人试图拦截数据，但没有一种方法可以完全解释受感染的端点。

于 2012-12-27T18:20:01.697 回答
5

Web 服务器通常支持“会话”的概念。当 Web 浏览器连接时，会在服务器上创建一个会话，该会话返回一个会话 ID（通常作为 HTTP cookie）。然后，Web 浏览器将该会话 ID cookie 发送到对服务器的所有后续请求。

使用这种机制，许多编程语言/框架都有一个身份验证/授权模块，它允许用户对自己进行身份验证（通常使用用户名和密码）。一旦验证了用户的身份，会话就会使用用户的 ID 进行更新）。然后，服务器代码检查每个请求的会话中的用户 ID，以确保用户经过身份验证/允许发出请求（无论是 HTML 页面视图还是 API GET/POST）。

对于 Android（或 iOS ......）应用程序而言，情况可能会有所不同，但想法是相似的：让用户验证自己一次，给客户端一个“秘密令牌”，该令牌在服务器中与用户记录一起映射。然后这个令牌被传递给客户端发送的所有请求。

您可以为此使用本地库或更标准的库，例如OAuth2。

于 2012-12-27T17:44:17.160 回答