2.3 漏洞分类与案例
2.3 漏洞分类与案例
本节摘要：SOURCE 2.3 把移动漏洞分为八类：不安全存储、通信、认证、授权、客户端注入、会话、弱加密、篡改/逆向。本节每类给一个可复现实验级别的案例摘要与修复验证方法。
本节地图
- 八类漏洞各举一例真实模式（非虚构公司名用「某金融 App」）
- 写出每类漏洞的「修复后如何复测通过」
- 理解客户端注入与 WebView 的关系
八类漏洞对照
| 分类 | 案例模式 | 复测方法 |
|---|---|---|
| 不安全存储 | JWT 在 logcat 打印 | 发布包 grep 无 token 日志 |
| 不安全通信 | SSLv3 降级 | testssl.sh / sslyze |
| 不安全认证 | 离线 PIN 仅本地比对 | 断网仍能「登录」则 fail |
| 不安全授权 | 修改 API 的 orderId 看别人订单 | 自动化 IDOR 用例 |
| 客户端注入 | WebView loadUrl(javascript:...) |
注入 payload 无执行 |
| 不当会话 | Refresh 无 rotation | 旧 refresh 仍可用则 fail |
| 弱加密 | ECB 模式加密手机号 | 密码学审计 |
| 篡改/逆向 | 重签 APK 仍可运行 | 完整性校验失败退出 |
漏洞分类树
漏洞分类树
案例：客户端注入 (WebView)
// 危险：反射 JavaScript 接口 + 未过滤 URL webView.addJavascriptInterface(new JsBridge(), "Android"); webView.loadUrl(userSuppliedUrl);
攻击：javascript:Android.exec('id')。修复：禁用 JS 接口、域名白名单、WebViewClient.shouldOverrideUrlLoading 拦截非 https。
案例：不当会话
Refresh Token 30 天有效且无设备绑定 → 偷一次 refresh 长期有效。修复：
- Access 15min + Refresh 7d
- Refresh 单次使用（rotation）
- 绑定
device_id与 IP 风控
案例：弱加密
用 DES 加密本地缓存 — 密钥长度不足。应改用 AES-256-GCM，密钥由 Android Keystore 生成且不可导出。
⚠️ 常见坑：只测 Happy Path 登录，未测「注销后会话是否失效」。
💡 关键直觉：分类是为了测试用例全覆盖，不是给开发扣帽子。
要点串联
- 八类漏洞覆盖 OWASP M10 大部分场景
- 每类需「攻击步骤 + 修复 + 复测」三联
- WebView 是客户端注入高发区
- 会话管理要在服务端可撤销
第 3 章进入安全开发：如何把上述漏洞消于编码阶段。
深化：每类漏洞的复测闭环
漏洞管理的价值在于「修复后能证明不再存在」。每类漏洞都要写下三连：攻击步骤、修复手段、复测方法。复测不能只看代码改没改，要重新跑一次攻击路径。例如 IDOR 修复后，用另一个账号的订单 id 重放请求，应返回 403；WebView 注入修复后，注入 payload 应无执行；弱加密修复后，加密输出应改用 AES-GCM 且密钥不可导出。
// 复测思路：WebView 注入防护后，预期 payload 不执行 webView.loadUrl("javascript:Android.exec('id')"); // 断言：Android.exec 无响应 / 白名单拦截跳转
客户端注入的边界要清楚：WebView 里跑的是 Web 代码，JavascriptInterface 暴露的是原生能力。凡是有 JS 桥的应用，必须做到三件事：桥接口最小化、域名白名单、关闭文件访问。攻击者一旦拿到 JS 执行能力，配合暴露的桥就是远程命令执行。
| 漏洞类 | 攻击步骤 | 复测通过标准 |
|---|---|---|
| IDOR | 改资源 id 重放 | 返回 403 |
| WebView注入 | 注入 javascript payload | 无执行 |
| 弱加密 | 检查算法与密钥 | AES-GCM 且密钥不可导出 |
| 会话 | 旧 refresh 重放 | 已作废 |
漏洞验证的边界与注意事项
做漏洞验证必须守两条边界：授权与范围。只对自有或书面授权的 App 测试，不碰生产数据；复现步骤尽量用测试账号，涉及用户数据用虚构样本。模拟器与真机的差异也要记录：模拟器环境宽松，很多本地威胁（Root 读取、硬件密钥）只能在真机上验证，报告里要注明测试环境。另外，「未发现」不等于「不存在」——报告要写清覆盖范围与未测项，让评审对风险边界有准确认知。
| 边界项 | 要求 | 常见失误 |
|---|---|---|
| 授权 | 书面授权 | 越权测试 |
| 环境 | 真机+模拟器并测 | 只在模拟器 |
| 数据 | 测试账号/虚构样本 | 碰生产数据 |
| 报告 | 注明覆盖与未测项 | 只写结论 |
复测的自动化
复测尽量自动化：IDOR 用脚本批量重放不同资源 id，WebView 注入用固定的 payload 集合，会话用旧 Token 重放脚本。自动化用例放进回归测试套件，每次发版自动跑，能拦住大部分回归漏洞。手动复测只保留需要人工判断的项，如业务逻辑歧义。自动化与手动结合，是漏洞管理从「人肉追」走向「流程闭环」的关键一步。
漏洞闭环的复盘节奏
漏洞闭环后要定期复盘：近一个季度哪些漏洞类型反复出现？哪类修复总是拖期？回归漏洞集中在哪个模块？复盘结论要落到改进动作上——新增测试用例、补强规范、调整优先级。复盘不是「看看数字」，而是把漏洞管理从被动响应推向主动预防的手段。