【问题标题】:How can I prevent other iOS/Android apps from using my RESTful API?如何防止其他 iOS/Android 应用程序使用我的 RESTful API?
【发布时间】:2014-05-11 13:26:26
【问题描述】:

我有一个预先存在的 iOS 和 Android 应用程序,我正在对其进行更新,其中包括一个 RESTful 服务 API 和用于用户身份验证的 Facebook 登录。该应用程序的一般流程是:

  1. 用户通过 Facebook 的 SDK“登录”到我的应用,这会将访问令牌返回给我的应用。
  2. 应用调用 RESTful 服务,包括 Facebook 访问令牌作为参数(使用 HTTPS 和 SSL)
  3. 被调用的服务将接收到的访问令牌(以及仅存储在我的服务器上的应用程序机密)发送到 Facebook 以验证用户是谁,并基于此执行操作。 Facebook 设置为要求服务器端调用的应用程序机密。

我的应用程序已经流行起来并且已经有几个克隆,我想阻止这些克隆能够使用我的 RESTful API(我相信他们会在我发布更新时尝试这样做)。让我们假设克隆是智能的,使用与我的应用相同的 Facebook 访问令牌(如果可能的话),并且遵循与我的应用类似的模式和调用 API 的频率。

是否有办法确保或几乎确保对我的服务的调用仅来自我的应用程序,而不是克隆?

提前致谢!

【问题讨论】:

标签: android ios security rest


【解决方案1】:

您可以通过在请求中包含签名并对其进行验证来做到这一点。

应用端:

  1. 执行类似的操作:signature = md5( md5(url + data) + MY_RANDOM_KEY)

  2. signature附加到数据或url等

  3. 发送对 REST api 的调用(像往常一样)

服务器端:

  1. 从正文/url 中提取signature(并从那里删除)。

  2. 计算您认为应该是什么:signature_should_be = md5( md5(url + data) + MY_RANDOM_KEY) [请记住,您已从 url/data 中删除了 signature,以便您获得原始预哈希状态的 url/data]

  3. 验证signaturesignature_should_be 是否相等

这样做,连同 SSL,应该使您的 API 足够安全。

【讨论】:

  • 不,抱歉,我没喝过咖啡,没关系。
  • 我担心使用这种方法是克隆可以对我的应用程序进行逆向工程,看看我会在这里做什么。如果克隆还使用了签名 = md5(md5(url + data) + MY_RANDOM_KEY),如我的应用程序中所见,那么这将如何使其安全?另外,我认为MD5已经过时了一段时间了。
  • 从某种意义上说,你是对的。但在同样的意义上,他们也可以对你做的任何其他事情做同样的事情。使用你想要的任何散列。如果MY_RANDOM_KEY 足够长,并且您还使用哈希哈希(嵌套的 md5 调用),那么您会没事的。如果您的MY_RANDOM_KEY 遭到入侵,那么是的,您有问题。但这是一般的身份验证。除非您携带银行数据或类似的东西,否则就可以了。
  • 还有一些方法可以确保它与下一秒不同。您可以将TIME_SINCE_EPOCH 附加到MY_RANDOM_TOKEN,然后服务器端在过去和接下来的 5 秒内使所有有效的signature_should_be (以考虑各种延迟等)。但对于你可能想要保护的东西,这太过分了。
  • 我明白你在说什么@TommyCrush,但我应该在哪里存储 MY_RANDOM_TOKEN?如果我将它存储在客户端,如果他们只是反编译我的代码,那不是很容易发现吗?
【解决方案2】:

您可以按照 Tommy Crush 的建议进行操作,并在您的应用程序中添加一个秘密。但如果你遇到聪明的对手,这可能无济于事。攻击者可以反编译您的应用程序或尝试简单地对您的签名算法进行逆向工程。

重要的是要记住,存储在您的应用程序中的任何内容都应该被认为已经受到攻击,因为攻击者可以反编译您的应用程序并尽可能多地搜索您的代码并从中提取他/她想要的任何内容.您不能依赖应用程序中的任何内容来确保应用程序内部的安全,因为攻击者可以将其从您的应用程序中提取到他们的应用程序中。

请务必注意,您正在尝试使用 OAuth 进行身份验证,而这并不适用。它只是用于授权,与身份验证不同。授权只是让您访问资源,但不会告诉您谁访问了它,这是您面临的问题。要将您的用户验证为您的真实用户(或尽可能接近),您需要为您的服务添加登录服务 - 例如滚动您自己的 OAuth 服务器或类似的东西。然后你可以决定谁可以访问资源,在这种情况下是你的 RESTful API :) 如果这比它的价值更多,那么汤米的方案是一个不错的选择:)

【讨论】:

  • 但问题是,我不想在 Facebook 之外拥有单独的登录服务......我认为这会让用户不得不登录我的应用程序以及链接他们的Facebook 帐户。
  • 另一个问题:OAuth 服务器如何保证 API 使用来自我的应用程序,而不是任何其他对我的代码进行逆向工程的应用程序开发人员?
  • 不幸的是,正如您所建议的,攻击者可以告诉他们的用户注册到您的站点以克服该障碍。一旦注册,他们就可以作为有效的注册用户访问您的 API。您可以尝试通过加强您网站的注册来规避这种情况。确保您只允许来自您的域而不是其他域的注册人,使 CRSF 难以使用 nonce 等。然后攻击者用户可能会看到诈骗者的身份并加入您。抱歉,如果这太难以理解 - 现在是凌晨 4 点:P
  • 这里的简短回答是,这里没有 100% 安全的 API。任何时候源代码被泄露,处理它的数据也会被泄露。没有办法解决这个问题。我提出的解决方案几乎是标准的,并且会阻止绝大多数黑客进一步行动。
【解决方案3】:

在 Twitter 和 Facebook 等 RESTful API 上进行身份验证的实际解决方案是 OAuth 机制。 您可以在此处找到更多详细信息:http://en.wikipedia.org/wiki/OAuth

大多数带有外部库的语言都支持 OAuth。 例如,在 Android 上,有 https://github.com/wuman/android-oauth-client 库。

【讨论】:

  • 这本质上与他/她想要达到的目标不同。
猜你喜欢
  • 2022-01-08
  • 1970-01-01
  • 1970-01-01
  • 2013-09-12
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-08-14
  • 1970-01-01
相关资源
最近更新 更多