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

Question

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

但是，我正在处理的iPhone应用程序正在与我构建的REST API进行通信（我已经控制了应用程序和服务器 - 因此欢迎任何建议）。

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

我正在谈论的API将在我发布应用程序时公开。 所以我不一定担心别人能够对它进行API调用。

我关心的是：

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

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

如果应用程序需要使用客户端ID /客户端密码，您能想到保护客户端ID /客户端密钥的方法吗？

Answer 1

我知道这不是你所希望的答案，但不幸的是，我认为你无法绝对保证完成你的目标。 在一天结束时，您无法信任您无法控制的客户，并且一旦离开您就无法控制它。

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

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

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