渗透测试-Android-App渗透测试测试流程
0x01：前言：
仅作为记录以供参考
0x02：漏洞测试方法以及修复方案
一、组件以及源码安全
1、签名校验
命令：
//test.apk 为要检测的包
jarsigner.exe -verify test.apk -verbose –certs
如果显示jar已验证即为已做了签名校验
修复方案：增加验证签名机制。
2、任意调试漏洞
通过对apk文件进行解包，检测 AndroidManifest.xml 文件的 debuggable 属性，如果该属性为 true，则存在任意调试漏洞。
解包过程：
命令：
//test.apk为要拆解的包名 test为拆解后存放的文件夹 java -jar apktool_2.4.0.jar d -f apl test.apk -o test
使用编译器打开XML文件，搜索关键字 debuggable ，如果存在该属性且为 true ，则存在任意调试漏洞，如果不存在该属性则不存在该漏洞（debuggable默认为false）
修复方案：将 debuggable 改为 false。
3、AllowBackup漏洞
通过对apk文件进行解包，检测 AndroidManifest.xml 文件的 allowBackup 属性，如果该属性为 true，则存在 allowBackup 漏洞。用户可通过adb backup来进行对应用数据的备份，在无root的情况下可以导出应用中存储的所有数据，造成用户数据的严重泄露。
使用编译器打开XML文件，搜索关键字 allowBackup ，如果存在该属性且为 true ，则存在allowBackup漏洞，如果不存在该属性也存在该漏洞（allowBackup默认为true）
修复方案：将 allowBackup 改为 false。
4、APP代码未混淆
使用 dex2jar 对apk文件内的 classes.dex 文件处理得到 classes-dex2jar.jar 文件，使用 jd-jui 反编译jar文件得到源码，如果代码未混淆，即代码的类名、函数、变量等未变为无意义的字符，则有源码暴露、资源文件暴露、主配文件篡改、核心SO库暴露、暴力破解恶意利用等风险。
操作方法：
使用解压缩包软件打开apk文件，将classes.dex文件复制出来。
使用 dex2jar 将classes.dex处理为jar文件
命令：
./d2j-dex2jar.bat /d/渗透测试/移动app渗透/dex2jar-2.0/classes.dex
然后使用jui打开jar文件，如果代码未混淆，将是下面这个样子
已经混淆的，如下
修复方案：将代码进行混淆加密。
5、APP未作应用完整性校验
未检测app的MD5或CRC32、SHA1准确性以及完整性，导致可以修改app任意文件二次打包。
拆包后将 app logo 文件替换为其他图片，一般存在于res文件夹下的以mipmap开头的几个文件夹中，或者直接在apk文件夹下搜索launcher、logo 。然后重新打包签名，查看是否可以正常安装使用
过程如下：将app拆包后更换app的logo文件
重新打包apk，打包生成的apk文件默认存放在apk文件夹中dist文件夹下：
命令：
//test指要打包的文件夹
java -jar apktool_2.4.0.jar b test/
将apk签名：
命令：
//test.apk是要签名的apk test1.apk是签名后输出的apk
java -jar signapk.jar testkey.x509.pem testkey.pk8 test.apk test1.apk
尝试安装，如果可以正常安装且可以正常打开使用，代表存在app未作应用完整性校验
修复方案：在app安装时首先进行CRC32、MD5或SHA1校验，校验与源app值相同时才可以正常安装，否则禁止安装或设置开启app自动关闭
6、APP敏感数据泄露
主要检测软件包内的db数据库是否泄露了敏感信息，本地数据库有可能明文保存用户的账号密码或其他信息。
将手机和pc连接，pc部署adb环境，手机需要root，adb进入手机系统
命令：
adb shell
切换root权限，命令：
su
进入/data/data目录，此目录是用户安装的软件目录
选择要进入的包，包名在 AndroidManifest.xml 文件中，通过搜索package可以得到
进入相应的包，查看文件目录，应该存在database目录
进入该目录，查看文件，导出.db文件
命令：
cp xx.db /sdcard/
然后在sd卡，也就是手机内部存储器即可可见数据库文件
使用数据库管理工具SQLiteExpert打开即可
未完待续……
二、逻辑漏洞
1、邮件炸弹
存在点：存在于任意可发送验证码的位置，发送验证码一般都有限制时间。
验证方法：输入手机号、邮箱后抓包后多次重放，如果接到许多验证码即代表存在邮件炸弹。
产生原因：服务器未作后端校验，只是在前端设置了60s冷却时间，但是服务端并与前端进行联合校验，导致可以绕过限制时间不停发邮件或验证码。
修复方案：服务端记录邮件发送冷却时间，与前端其进行联合校验。
2、任意用户密码重置
存在点：找回密码和修改密码处
验证方法：1.修改密码，修改自己的密码，输入正确信息后抓取发送数据包，然后改变手机号（或邮箱）这一参数，将它改为其他手机号（或邮箱），然后发出数据包。
2.找回密码，输入自己的手机号（或邮箱），获取验证码，然后输入正确的验证码，抓包，将手机号（或邮箱）这一参数改为其他用户的手机号（或邮箱），发送数据。
产生原因：1.输入密码后提交到服务端的post数据包需要包含当前用户的身份信息，而一般网站是通过用户名或用户ID来标识用户身份的，如果这个用户名或用户ID没有和当前手机号、短信验证码进行绑定，也就是说服务端只验证用户名、ID是否存在，而不去验证用户和当前手机号是否匹配，那么我们就可以通过修改用户名、ID去修改其他用户的密码了。
2.漏洞原因判断了验证码是否正确，而没有判断该验证码是否跟该用户匹配。
修复方案：对参数进行复杂加密，将用户名、验证码和手机号进行绑定，输入新的密码，然后提交到服务端，服务端应对当前用户名、手机号、短信验证码进行二次匹配验证，都为true时，才可以修改成功。
未完待续......
