3

我们一直在我们的 android 应用程序中实现 Facebook Android SDK，它需要将应用程序签名存储在 facebook 服务器上，以便可以验证从应用程序到 facebook 的调用。我们想将此系统用于我们自己的后端，以确保它仅被我们的应用程序使用，对此我有以下问题：

（参考https://github.com/facebook/facebook-android-sdk/tree/master/facebook/src/com/facebook/android找到相关类）

  1. 显然，要通过匹配签名来验证调用，需要将应用程序的签名发送到服务器。在 sdk 中，我似乎无法找到这是在哪里完成的？
  2. 好像没有使用https，对吗？（实用程序.java）
  3. 难道不能嗅探签名使整个系统毫无意义吗？
  4. Facebook.java 在文件底部保存 facebook 应用程序的签名。改变这一点似乎微不足道。但是，据我了解，发送 Intent 的应用程序的签名可以通过该 Intent 解决。Android 系统对此进行管理，因此无法伪造签名。但是，在调用 url 时，Android 系统能否以不可变的方式将签名添加到协议中？我猜不是，这让我对上述问题感到好奇。

[编辑回复 nitzan & zapl]

我要实现的目标与 facebook sdk 要求您将签名存储在其服务器上的原因相同；确保对我们后端的调用是从我们的应用程序发送的，而不是其他任何东西。我们不想让机器人或其他应用程序访问我们的服务器 API。facebook sdk 有方法来检查 Intent 是否来自 Facebook 应用程序，这是安全的，因为 Android 系统对签名和 Intent 的封闭管理。解决此问题的唯一方法是运行修改后的 Android 版本，该版本允许覆盖应用程序签名，但人们构建和运行的几率可以忽略不计。但是，运行应用程序、嗅探通过非 https 协议发送的签名并构建使用此签名和 api 调用的应用程序不是。似乎使这样一个系统工作的唯一方法是使用 https，

请注意，我在上面描述的 Intent 验证方法与对 facebook 服务器的 url 调用不同。Intents 用于让设备上的 Facebook 应用程序与实现 SDK 的应用程序进行通信。Android 系统确保与传入 Intent 一起发送的 Facebook 应用程序的签名不会被伪造，因此 Facebook 应用程序->应用程序通信系统是安全的。与这个内部系统相反，我的问题是关于到服务器的传出 url 调用的外部系统，如果签名可以在调用中不可变地发送，这将是安全的，基本上实现与 Intent 系统相同的系统。

[编辑 2]

与我们假设的相反，事实证明应用签名很容易获取。虽然应用程序需要使用私有开发人员密钥进行签名，但这不会损害 Android 上应用程序的安全性，但它显然不能用于验证 api 调用服务器端。

这就引出了更多问题：

  1. 为什么 Facebook 实施这个系统，而它很容易被攻破？
  2. 是否有任何其他已知的实现来限制服务器 api 仅访问特定应用程序？（混淆除外）
4

2 回答 2

1
  1. 我不知道。
  2. 是的，它似乎正在替换fbconnect://Uri，http://这意味着使用此代码的连接没有加密。
  3. 我想是的，试着验证一下。
  4. 改变它是没有问题的，你可以反编译apks，改变一些代码，如果你愿意，可以将它们编译回来。你唯一不能做的就是再次签署apk（你缺少所需的密钥）。或者您可以在自己的代码中使用签名。
    您的应用程序的签名检查发生在安装时，如果您的签名不符合要求，您在清单中请求的权限将被删除。如果您更新您的 apk，新 apk 的签名将与旧的现有 apk 进行检查，如果签名不匹配，升级将失败。但是你可以卸载旧的并安装你的假的。
    如果您从您的应用程序发送和 Intent，系统可能包含发件人的包，您无权更改它。

而且对服务器进行验证的全部目的最终并不是安全问题，因为没有防弹的方法来验证应用程序。它用于使其他人更难滥用 API，并用于跟踪谁在使用该 API。

身份验证机制要求您的 apk 中有某种密钥。但是，由于您将该 apk 发送给潜在的邪恶客户，因此您无法再控制它，并且可能会提取密钥并滥用它。您所能做的就是混淆密钥，以便更难获得它。但这最终是不可能的。

因此，假设您有一个与您的后端服务器通信的应用程序，并且我将您的应用程序下载到我的设备上。然后我可以.apk从我的设备上取下来，反编译它并找到与你的服务器的通信是如何工作的——在创建 https 之前的明文。我还可以看到您的应用程序的签名是什么，它存储在设备上的 xml 文件和 apk 中。然后我要么修改你的应用程序，要么创建一个新的应用程序，它使用这些信息的行为与你的完全一样，只是它不是你的应用程序。使用 https 没问题，我也可以给你发你想要的签名。

你无法阻止这种情况发生。你只能让它很难做到。

于 2012-04-29T13:55:31.890 回答
0

为了验证在不受信任的设备上运行的应用程序，服务器必须执行一些操作，例如要求来自应用程序的通信使用只有应用程序持有的密钥进行数字签名。

应用程序作者必须在应用程序中隐藏密钥，以便相对难以提取以用于冒名顶替者。但不能让它无法提取。

拥有应用程序提取密钥的冒名顶替者不应仅基于此能够伪装成任意用户，但它可以允许具有真实密码的真实用户从应用程序的伪装版本（有意或无意）登录. 请注意，对于旨在简单地从不知情的用户那里窃取密码的虚假应用程序而言，实际上能够登录服务器可能不是必需的。

SSL 对保护应用程序本身没有什么价值，因为应用程序可以安装在 SSL 损坏的平台上，或者修补以破坏内部 SSL 实现以完成拦截。但是，有效的 SSL 可以帮助保护未受损设备上的应用程序用户。

于 2012-04-29T17:27:48.997 回答