在 iPhone 应用程序中使用 REST API 时的安全性

Question

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

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

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

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

我关心的是：

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

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

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

Answer 1

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

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

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

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