2.2 OWASP Mobile Top 10
2.2 OWASP Mobile Top 10
本节摘要：OWASP Mobile Top 10 是移动渗透与合规的共同语言。SOURCE 2.2 逐条解释 M1–M10；本节为每条给出典型缺陷代码、MobSF 规则 ID 思路与修复优先级，便于 Sprint 排期。
核心问题
- 背诵 M1–M10 名称及核心风险一句话
- 将 MobSF/Checkmarx 发现映射到 M 编号
- 制定 P0/P1 修复顺序（存储与通信优先）
OWASP M1–M10 速查
| 编号 | 名称 | 典型缺陷 | 修复要点 |
|---|---|---|---|
| M1 | 不安全的数据存储 | Token 明文 prefs | EncryptedSharedPreferences |
| M2 | 不安全的通信 | HTTP、弱 TLS | HTTPS + Pinning |
| M3 | 不安全的认证 | 仅客户端校验密码 | 服务端 MFA |
| M4 | 不安全的授权 | IDOR userId=123 |
服务端 RBAC |
| M5 | 不安全的密码学 | MD5、硬编码密钥 | AES-GCM + Keystore |
| M6 | 客户端代码篡改 | 无签名校验 | Play Integrity |
| M7 | 逆向工程 | 密钥在 APK 字符串 | 服务端下发 + 混淆 |
| M8 | 多余功能 | 隐藏 debug 菜单 | 生产包剥离 |
| M9 | 不可信输入 | WebView JS 注入 | 输入验证 |
| M10 | 不当会话处理 | Token 永不过期 | 短 TTL + Refresh |
OWASP M10 风险关系
OWASP M10 风险关系
深度示例：M1 与 M2 连锁
某外卖 App：
- M2：登录 API 走 HTTP（仅测试环境配置泄漏到 prod）
- M1：登录成功后 Token 写
SharedPreferences无加密 - 攻击者在咖啡店 Wi-Fi 抓包 + 偷手机读 prefs → 完整账号接管
修复顺序：先 M2（全站 HTTPS + HSTS 思路），再 M1（加密存储），再 M10（Token 2h 过期）。
M6/M7：篡改与逆向
- M6：重打包去广告 → 攻击者插入键盘记录
- M7：
apktool d+ jadx 读 API Key → 刷接口
对策：Google Play App Signing + R8 混淆 + 服务端 API 限流与设备绑定；iOS 用 App Store 加密与 bitcode/符号剥离。
渗透报告写法
## 发现 #1 [Critical] M2 不安全的通信 - 位置：NetworkSecurityConfig 允许 cleartext - 证据：Burp 明文 POST /api/login - 建议：cleartextTrafficPermitted=false + Pinning
⚠️ 常见坑：只修 M1 加密存储，忽略 M4 水平越权——加密了仍能被同设备其他漏洞读出。
💡 关键直觉：M 编号用于排优先级与沟通，不是互斥分类——一条链常跨多个 M。
本章回顾
- M1/M2/M3/M4 是账号与数据类 P0
- M6/M7 影响代码与商业逻辑保护
- 报告需证据 + M 映射 + 可验证修复
- MobSF 静态报告是 M1/M5/M8 的快速入口
下一节按漏洞类型（存储/通信/认证…）做更细分类。
深化：M 条目的分组与排期逻辑
M1–M10 可以按「数据类、身份类、代码类」分三组记忆：M1/M2/M5 直接决定数据能否被偷走，M3/M4/M10 决定账号能否被接管，M6/M7/M8/M9 决定代码与商业逻辑能否被破坏。排期时按「从外到内」修复：先通信（M2）堵住入口，再存储（M1）防住落地，然后认证授权（M3/M4）与会话（M10），最后代码层（M6/M7）与输入（M9）。这个顺序同时是渗透测试的排查顺序。
# 修复优先级示例（问题驱动） P0 当天 : 明文传输密码(→M2)、空 TrustManager(→M5) P0 3天内 : 明文 Token 存储(→M1)、IDOR 接口(→M4) P1 两周 : 无 MFA(→M3)、Refresh 无 rotation(→M10) P2 计划内 : 未混淆(→M7)、多余功能(→M8)
用「威胁能否被低成本利用」决定优先级，而不是「漏洞类型」：能被远程触发的 IDOR 永远高于只能本地利用的日志泄露。评审会上一张优先级表比十页原理更有说服力。
| 分组 | 条目 | 共同风险 | 优先修复 |
|---|---|---|---|
| 数据类 | M1/M2/M5 | 数据窃取 | P0 |
| 身份类 | M3/M4/M10 | 账号接管 | P0/P1 |
| 代码类 | M6/M7/M8/M9 | 业务破坏 | P1/P2 |
用 M 编号组织渗透报告
渗透报告用 M 编号组织，能让读者快速把握风险地图。推荐结构：每一条发现包含编号与严重度、位置（文件/接口）、复现步骤与证据、OWASP M 映射、修复建议、复测方法。证据优先用截图与抓包记录，复测方法要可执行。报告的目的不是「列出多少问题」，而是让开发与产品在十分钟内知道：哪些必须先修、怎么修、怎么验证修好了。
# 渗透报告条目模板 ## 发现 #2 [High] M4 不安全的授权 - 位置: GET /api/orders/{orderId} - 证据: 改 orderId 可读他人订单（Burp 截图） - 修复: 服务端校验 orderId 归属当前用户 - 复测: 用他人 orderId 重放，期望 403
M 编号还有排期作用：把条目按严重度与 M 分组，Critical/High 进发布阻断，Medium 进迭代计划，Low 进 backlog。这样风险与排期直接挂钩，避免「报告写完了但没人跟」。
| 报告要素 | 内容 | 目的 |
|---|---|---|
| 编号+严重度 | 决定优先级 | 排期 |
| 证据 | 截图/抓包 | 可信 |
| M 映射 | 对应条目 | 归类 |
| 复测方法 | 可执行步骤 | 验收 |
M 编号与验收标准的绑定
把 M 编号与验收标准绑定，能让修复有明确终点。例如 M1 的验收是「发布包内搜不到明文 token，注销后本地无残留」；M2 的验收是「装用户 CA 后无法解密关键 API」；M3/M4 的验收是「改包后无法越权、IDOR 用例全过」。验收标准写进修复单，开发与测试对齐口径，避免「改完了但没验证」的扯皮。
M 编号是沟通语言
M 编号最有价值的用途是沟通：安全测试说「M1 存在」，开发立刻知道「Token 存储要改加密」；产品说「M4 是 P0」，排期就有依据。把 M 语言普及给团队，比任何流程文档都有效。这也是它出现在渗透报告、修复单、验收标准里的原因。