1 背景
【工匠若水 http://blog.csdn.net/yanbober 转载烦请注明出处。尊重劳动成果】
事实上这篇文章可能有些小题大作，但回过头想想还是非常有必要的，有点阴沟里翻船的感觉。相信大家都知道Android API Level 8開始提供了为应用程序备份和恢复数据的功能。此功能的开关能够通过应用程序中AndroidManifest.xml文件的allowBackup属性值进行配置，默认是True。所以用户能够对我们应用程序进行数据备份。相信非常多人都和我一样一直当作耳边风过了一下Android这个特性，然后就一直没再打理了。然而旧事重提的故事是以下这样開始的：
前不久突然收到了一个Bug反馈。来自国内著名的白帽子组织乌云平台，关于这个组织就不作介绍了，相信大家一定知道问题的严重性，关于修复这个Bug是非常快的事情。可是修复完这个Bug以后不得不让我进入思考（就像之前处理SQL注入一样），所以写出此文记录。
事实上allowBackup的风险原理主要是同意通过adb backup对打开USB调试的设备进行数据备份。一旦得到备份文件之后那就不好说了，譬如邪恶的人能够再通过adb restore将你的数据恢复到自己的设备上，然后就全然在自己的设备上以你的名义去玩弄App。或者通过代码分析出备份文件里你登陆App的一些账户password等核心信息。总之。Google当初设计的核心肯定是为了方便备份数据考虑的，可是大家自己开发的应用似乎忽略了手机丢失或者被他人捡到的问题。譬如通讯录或者名片、支付类等App假设一旦出现此类问题后果还是非常严重的，所以有必要重视一下。
2 实例还原
为了验证该小问题可能带来的重大敏感信息泄露问题，我们以下选几个代表App进行測试，这样就能够直观的让你感受到泄露的一点危机。
特别声明： 本文实例中涉及的应用仅仅为验证，且本问题一般不会造成太大风险，故烦请大家保持学习心态而不要肆意污蔑应用开发人员。当然我也已经通过乌云漏洞平台对以下涉及到的应用进行了漏洞提交。相信这些应用新的迭代版本号中非常快就会解决掉的。
《简书》Android 1.9.7版本号測试
结论： 会存在帐号被盗取问题。
验证： 设备A上登陆帐号password后例如以下：
然后在该设备上运行例如以下命令将数据备份到电脑上：
XXX@ThinkPad:~/workspace/myself/temp$ adb backup -f back.ab -noapk com.jianshu.haruki
Now unlock your device and confirm the backup operation.此时换一台设备B安装此应用。可是不登陆不论什么帐号password，运行例如以下命令：
XXX@ThinkPad:~/workspace/myself/temp$ adb restore back.ab
Now unlock your device and confirm the restore operation.能够看见，设备B没有进行帐号password登陆。仅仅是通过恢复A设备的备份数据就成功登陆了A设备的信息。
《Sina微博》Android 5.1.0版本号測试
依照上面的相似流程測试微薄发如今设备B上面恢复设备A的数据无效，设备B依然显演示样例如以下：
也就是说Sina微博考虑的非常周全，已经修复了此类潜在的泄露风险，备份数据恢复无效，依然须要又一次登陆才干够。给一个赞。
《薄荷》Android 5.4.5.1版本号測试
这个应用根据上面相似操作后你会发现全然能够在设备B上不用登陆帐号，仅仅用恢复别人的备份帐号信息就可以进入别人帐号界面。例如以下：
上面为设备B上截图情况，直接能够在设备B上操作设备A的帐号。
3 反思与总结
【工匠若水 http://blog.csdn.net/yanbober 转载烦请注明出处，尊重劳动成果】
看了上面两部分的叙述以后你可能也会意识到这个问题潜在的严重性。Google的初心是好的，可是一旦被别实用心的人瞄上了这个突破点问题就严重了。
譬如再高端一点，别实用心的人专门写一段代码去运行数据备份上传到自己的云端server。然后解析这些备份数据，小则个人信息泄露，大则哈哈，你懂的。
既然这样肯定你也会关心解决方式吧，详细解决比較easy。例如以下：
方案1:
直接在你的Android清单文件里设置android:allowBackup=”false”就可以。例如以下：
<?xml version="1.0" encoding="utf-8"?
>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.test.disallowbackup"
android:versionCode="1"
android:versionName="1.0">
<uses-sdk android:minSdkVersion="10"/>
<application
android:allowBackup="false"
android:label="@string/app_name">
<activity android:name="LoginActivity"
android:label="@string/app_name">
<intent-filter>
<action android:name="android.intent.action.MAIN"/>
<category android:name="android.intent.category.LAUNCHER"/>
</intent-filter>
</activity>
</application>
</manifest>方案2:
不在你的Android清单文件里设置android:allowBackup=”false”，同意运行备份，可是在你应用启动页进行逻辑推断是否进行又一次登陆等，譬如查看设备唯一识别设备编号和备份前是否一致，不一致则直接跳转登陆页面的同一时候清空当前应用数据及缓存。
好了，个人愚见，不足说服力，仅仅是由于项目被乌云反馈而写的一点总结而已，眼下我们採用了相似新浪微博的方案1做法。
【工匠若水 http://blog.csdn.net/yanbober 转载烦请注明出处。尊重劳动成果】
