7、OWASP Mobile Top 10：M1-M5漏洞详解与检测方法
OWASP Mobile Top 10，说白了就是移动安全领域的「必考清单」。我入行那会儿，这玩意儿还没这么普及，踩了不少坑才明白它的分量。今天咱们就聊聊前五个最要命的漏洞——M1到M5。你想想看，一个App如果连这五关都过不了，上线基本就是裸奔。
7.1 M1：不当使用平台特性
这个漏洞，我习惯叫它「滥用系统API」。说白了就是开发者调用了不该调用的接口，或者用错了方式。比如WebView的addJavascriptInterface，很多人图方便直接暴露给JS，结果被远程代码执行。
核心风险点：
- WebView组件未正确配置（JavaScript接口暴露）
- Intent隐式调用导致组件劫持
- Content Provider权限配置不当
- Keychain/Keystore使用错误
我在项目中遇到过一家金融App，他们的登录页面用了WebView加载H5，结果addJavascriptInterface暴露了一个能读取本地文件的方法。攻击者只要诱导用户点个链接，就能把通讯录、短信全拿走。嗯，这锅得开发背。
检测方法
// 静态扫描：检查WebView配置
adb shell dumpsys package com.example.app | grep "WebView"
// 动态检测：尝试Intent劫持
adb shell am start -a android.intent.action.VIEW -d "example://open"我的建议：别用addJavascriptInterface，改用JavaScriptInterface注解，并且只暴露最小必要接口。实在要用，记得做URL白名单校验。
7.2 M2：不安全的身份验证
这个漏洞太常见了。我见过最离谱的——某App的登录接口，直接把用户名和密码明文POST出去，连HTTPS都没用。你想想看，这跟在大街上喊「我密码是123456」有什么区别？
M2的核心问题在于：身份验证机制存在缺陷。包括但不限于：
- 本地存储明文密码或Token
- 弱密码策略（允许123456）
- 会话Token固定或可预测
- 生物认证绕过（比如指纹验证被降级）
注意：我曾经在审计一个社交App时发现，他们的Token生成算法居然是System.currentTimeMillis()拼接用户ID。攻击者只要注册几个账号，就能推算出别人的Token。这漏洞我报了高危。
检测方法
// 抓包检查认证流程
mitmproxy -p 8888
// 检查本地Token存储
adb shell run-as com.example.app cat /data/data/com.example.app/shared_prefs/*.xml7.3 M3：不安全的通信
说白了就是数据传输没加密，或者加密方式不对。我经常跟团队说：「网络传输就像寄明信片，谁都能看」。如果你不用HTTPS，或者证书校验不严格，中间人攻击分分钟教你做人。
常见的坑有：
- HTTP明文传输（还在用？）
- HTTPS证书校验关闭（allowAllCerts=true）
- 自定义协议实现有漏洞（比如WebSocket没加密）
- SSL Pinning未实现或实现错误
真实案例：我审计过一个IoT配套App，它和硬件通信用的是自定义TCP协议，数据只做了简单的XOR加密。我用Wireshark抓包，5分钟就还原了控制指令。嗯，这App后来被要求重写通信模块。
检测方法
// 设置代理抓包
export http_proxy=http://127.0.0.1:8888
export https_proxy=http://127.0.0.1:8888
// 检查证书锁定
adb shell dumpsys wifi | grep "ssl"7.4 M4：不安全的存储
这个漏洞，我习惯叫它「数据裸奔」。很多开发者觉得数据存本地就安全了，其实Android的SharedPreferences、SQLite数据库、甚至外部存储，都是攻击者的提款机。
常见问题：
| 存储方式 | 风险 | 检测方法 |
|---|---|---|
| SharedPreferences | 明文存储密码/Token | 查看XML文件 |
| SQLite数据库 | 未加密的敏感数据 | 导出db文件分析 |
| 外部存储 | 任何App都可读取 | 检查/sdcard目录 |
| KeyStore | 密钥保护不当 | 检查密钥生成方式 |
避坑指南：我曾经在逆向一个电商App时，直接在/data/data/com.example.app/databases/下找到了明文信用卡号。开发者把加密密钥硬编码在代码里，用AES加密后存到数据库——但密钥就在隔壁的so文件里。这跟没加密有啥区别？
检测方法
// 导出数据库
adb shell run-as com.example.app cat databases/app.db > /tmp/app.db
// 检查外部存储
adb shell ls -la /sdcard/Android/data/com.example.app/7.5 M5：不充分的加密
M5和M4是孪生兄弟。M4是「没存好」，M5是「没加密好」。说白了就是：你加密了，但加密方式有问题。比如用DES、MD5这种过时算法，或者自己实现加密算法——我见过有人用Base64当加密用的，哭笑不得。
核心问题：
- 使用弱加密算法（DES、RC4、MD5）
- 密钥硬编码在代码或资源文件中
- IV（初始化向量）固定或可预测
- 加密模式使用不当（比如ECB模式）
警告：我审计过一个医疗App，它用AES/ECB/PKCS5Padding加密患者数据。ECB模式有个致命问题：相同的明文块会产生相同的密文块。攻击者通过分析密文模式，就能推断出部分数据内容。这要是被曝光，公司得赔到破产。
检测方法
// 静态分析：搜索加密相关API
grep -r "Cipher\|SecretKey\|KeyGenerator" app/
// 动态分析：Hook加密函数
frida -U -l hook_crypto.js com.example.app知识体系总览
下面这张图，是我梳理的M1-M5核心逻辑。你看一眼就能明白这些漏洞之间的关系：
这五个漏洞，说白了就是App安全的「五毒」。我个人的经验是：先抓M3和M4，因为通信和存储是最容易被攻击者利用的入口。M1和M2往往需要逆向分析才能发现，而M5通常是M4的「并发症」——存储没做好，加密再强也白搭。
总结一下：
- M1：别乱用系统API，尤其是WebView和Intent
- M2：认证机制要严谨，Token生成别偷懒
- M3：通信必须加密，证书校验不能关
- M4：敏感数据别裸奔，KeyStore用起来
- M5：加密算法选对，密钥别硬编码
嗯，这五个漏洞讲完了。你想想看，如果能把M1-M5都堵住，你的App至少能挡住80%的常见攻击。剩下的，就是M6-M10的事了。