数据库
首页 > 数据库> > Android应用开发allowBackup敏感信息泄露的一点反思,玩转MySQL

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

作者:互联网

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版本测试


这个应用依据上面类似操作后你会发现完全可以在

《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》

【docs.qq.com/doc/DSkNLaERkbnFoS0ZF】 完整资料开源分享

设备B上不用登陆帐号,只用恢复别人的备份帐号信息即可进入别人帐号界面,如下:

这里写图片描述

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

3 反思与总结

===========

【工匠若水 http://blog.csdn.net/yanbober 转载烦请注明出处,尊重劳动成果】

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

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

方案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”>

<application

android:allowBackup=“false”

android:label="@string/app_name">

<activity android:name=“LoginActivity”

android:label="@string/app_name">

方案2:


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

总结:

各行各样都会淘汰一些能力差的,不仅仅是IT这个行业,所以,不要被程序猿是吃青春饭等等这类话题所吓倒,也不要觉得,找到一份工作,就享受安逸的生活,你在安逸的同时,别人正在奋力的向前跑,这样与别人的差距也就会越来越遥远,加油,希望,我们每一个人,成为更好的自己。

料包括 数据结构、Kotlin、计算机网络、Framework源码、数据结构与算法、小程序、NDK、Flutter,

[外链图片转存中…(img-3lkalI0p-1640844024678)]
[外链图片转存中…(img-ZFlHAU3E-1640844024696)]

本文已被CODING开源项目:《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》收录

标签:备份,allowBackup,源码,MySQL,android,Android,设备
来源: https://blog.csdn.net/m0_65686886/article/details/122235319