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

Question

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

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

我使用OAuth2协议进行身份验证,这意味着我的"API密钥"是客户端ID和客户端密钥的组合,只需要传输即可获取access_token.之后,使用access_token包含请求主体的HMAC的头部(使用客户端秘密作为密钥)将所有请求发送到服务器.这种添加的唯一原因是有人无法使用JUST进行API请求access_token.

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

我关心的是:

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

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

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

Answer 1

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

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

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

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