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上登陸帳號密碼後如下：

然後在該設備上執行如下命令將數據備份到電腦上：

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

此時換一台設備B安裝此應用，但是不登陸任何帳號密碼，執行如下命令：

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”即可，如下：

方案2:

不在你的Android清單文件中設置android:allowBackup=”false”，允許執行備份，但是在你應用啟動頁進行邏輯判斷是否進行重新登陸等，譬如查看設備唯一識別設備編號和備份前是否一致，不一致則直接跳轉登陸頁面的同時清空當前應用數據及緩存。

好了，個人愚見，不足說服力，只是因為項目被烏雲反饋而寫的一點總結而已，目前我們采用了類似新浪微博的方案1做法。