Android应用开发allowBackup敏感信息泄露的一点反思

1 背景

其实这篇文章可能有些小题大作，但回过头想想还是很有必要的，有点阴沟里翻船的感觉。相信大家都知道Android API Level 8开始提供了为应用程序备份和恢复数据的功能，此功能的开关可以通过应用程序中AndroidManifest.xml文件的allowBackup属性值进行配置，默认是True，所以用户可以对我们应用程序进行数据备份。相信很多人都和我一样一直当作耳边风过了一下Android这个特性，然后就一直没再打理了。然而旧事重提的故事是下面这样开始的：

前不久突然收到了一个Bug反馈，来自国内著名的白帽子组织乌云平台，关于这个组织就不作介绍了，相信大家一定知道问题的严重性，关于修复这个Bug是很快的事情，但是修复完这个Bug以后不得不让我进入思考（就像之前处理SQL注入一样），所以写出此文记录。

其实allowBackup的风险原理主要是允许通过adb backup对打开USB调试的设备进行数据备份，一旦得到备份文件之后那就不好说了，譬如邪恶的人可以再通过adb restore将你的数据恢复到自己的设备上，然后就完全在自己的设备上以你的名义去玩弄App；或者通过代码分析出备份文件中你登陆App的一些账户密码等核心信息。总之，Google当初设计的核心肯定是为了方便备份数据考虑的，但是大家自己开发的应用似乎忽略了手机丢失或者被他人捡到的问题，譬如通讯录或者名片、支付类等App如果一旦出现此类问题后果还是很严重的，所以有必要重视一下。

2 实例还原

为了验证该小问题可能带来的重大敏感信息泄露问题，我们下面选几个代表App进行测试，这样就可以直观的让你感受到泄露的一点危机。

特别声明： 本文实例中涉及的应用只为验证，且本问题一般不会造成太大风险，故烦请大家保持学习心态而不要肆意污蔑应用开发者；当然我也已经通过乌云漏洞平台对下面涉及到的应用进行了漏洞提交，相信这些应用新的迭代版本中很快就会解决掉的。

《简书》Android 1.9.7版本测试

结论： 会存在帐号被盗取问题。

验证： 设备A上登陆帐号密码后如下：

然后在该设备上执行如下命令将数据备份到电脑上：

class = "hljs ruby" >XXX @ThinkPad :~/workspace/myself/temp$ adb backup -f back.ab -noapk com.jianshu.haruki
Now unlock your device and confirm the backup operation.

此时换一台设备B安装此应用，但是不登陆任何帐号密码，执行如下命令：

class = "hljs ruby" >XXX @ThinkPad :~/workspace/myself/temp$ adb restore back.ab
Now unlock your device and confirm the restore operation.

可以看见，设备B没有进行帐号密码登陆，只是通过恢复A设备的备份数据就成功登陆了A设备的信息。

《Sina微博》Android 5.1.0版本测试

按照上面的类似流程测试微薄发现在设备B上面恢复设备A的数据无效，设备B依旧显示如下：

也就是说Sina微博考虑的很周全，已经修复了此类潜在的泄露风险，备份数据恢复无效，依旧需要重新登陆才可以，给一个赞。

《薄荷》Android 5.4.5.1版本测试

这个应用依据上面类似操作后你会发现完全可以在设备B上不用登陆帐号，只用恢复别人的备份帐号信息即可进入别人帐号界面，如下：

上面为设备B上截图情况，直接可以在设备B上操作设备A的帐号。

3 反思与总结

看了上面两部分的叙述以后你可能也会意识到这个问题潜在的严重性，Google的初心是好的，但是一旦被别有用心的人瞄上了这个突破点问题就严重了。譬如再高端一点，别有用心的人专门写一段代码去执行数据备份上传到自己的云端服务器，然后解析这些备份数据，小则个人信息泄露，大则哈哈，你懂的。

既然这样肯定你也会关心解决方案吧，具体解决比较容易，如下：

方案1:

直接在你的Android清单文件中设置android:allowBackup=”false”即可，如下：

class = "hljs xml" >
"1" android:versionname= "1.0" package = "com.test.disallowbackup" xmlns:android= "http://schemas.android.com/apk/res/android" >
    "10" >





                "android.intent.category.LAUNCHER" >

方案2:

不在你的Android清单文件中设置android:allowBackup=”false”，允许执行备份，但是在你应用启动页进行逻辑判断是否进行重新登陆等，譬如查看设备唯一识别设备编号和备份前是否一致，不一致则直接跳转登陆页面的同时清空当前应用数据及缓存。

好了，个人愚见，不足说服力，只是因为项目被乌云反馈而写的一点总结而已，目前我们采用了类似新浪微博的方案1做法。