5

我知道这个问题以前曾以各种形式提出过。但是，我不是在寻找“使用 https”的答案。我已经在使用 HTTPS，而且我并不担心来回传输的有效负载的敏感性。

但是，我正在开发的 iPhone 应用程序正在与我构建的 REST API 通信（我可以控制应用程序和服务器 - 因此欢迎提出任何建议）。

我使用 OAuth2 协议进行身份验证，这意味着我的“API 密钥”是 Client ID 和 Client Secret 的组合，只需传输即可获取access_token. 之后，所有请求都使用 和包含请求主体的 HMAC 的标头发送到服务器access_token（使用客户端密钥作为密钥）。这种添加的唯一原因是有人无法使用 JUST 发出 API 请求access_token。

当我发布应用程序时，我正在与之交谈的 API 将被公开。所以我不一定担心其他人能够对其进行 API 调用。

我关心的是：

  • 人们能够使用我的应用程序的客户端凭据进行 API 调用（这意味着我无法在服务器端检测到它不是来自我的应用程序）
  • 人们能够滥用我的客户端 ID 允许他们拥有的额外范围，而传统 API 用户将不会拥有

我的猜测是这个问题并没有真正的解决方案（除了使用 UIWebView 和制作一个美化的 webapp），但我想我还是会在这里问。

如果应用程序需要使用客户端 ID/客户端密码，你们能想出一种方法来保护它吗？

4

1 回答 1

7

我知道这不是您所希望的答案，但不幸的是，我认为您不能绝对有把握地完成您的目标。归根结底，你不能信任一个你无法控制的客户，一旦它离开你的手，你就无法控制它。

为了实现您的两个目标，您需要验证访问 API 的客户端是您编写的。这样做的方法是使用公钥/私钥对。您需要将私钥嵌入到客户端中，它可以用来签署某些内容。这样服务器就知道请求来自您的客户端，而不是其他人的。这也将允许您将某些呼叫限制为仅对您的客户。

但是，这并不是万无一失的，因为精明的用户可以逆向工程并从您的应用程序中提取私钥并使用它来欺骗源。虽然不是防弹的，但它是防弹的，因为这样做需要大量的工作并且技术含量很高，特别是如果您使用缓冲涂抹、大量红鲱鱼等反 RE 技术时。

如果我是你，我会问自己如果有人确实入侵了它会造成什么类型​​的损害。如果您是 Facebook，那将是灾难性的。如果您为内部组织服务，那可能根本不是什么大问题。如果你不能承受一次滥用，那么你需要重新考虑你的设计，因为这个是行不通的。您根本无法信任您无法控制的代码，并且一旦客户端在其他人的设备上，您就无法再控制它。

于 2013-03-07T17:18:09.720 回答