4.2 动态应用安全测试
4.2 动态应用安全测试 (DAST)
本节摘要：DAST 在 App 运行时模拟攻击：抓包改参、SSL 绕过检测、运行时权限滥用、Frida Hook 敏感函数。SOURCE 1.7 强调渗透测试与 IAST；本节聚焦移动 DAST 实操环境搭建。
你能学到什么
- 配置 Burp/mitmproxy 对 Android 模拟器抓 HTTPS
- 验证 Certificate Pinning 是否生效
- 用 objection/Frida 枚举 Keychain/SharedPreferences
一、测试环境
| 组件 | 用途 |
|---|---|
| Genymotion / AVD | 可 root 镜像 |
| Burp Suite | HTTP(S) 代理、Repeater |
| mitmproxy | 脚本化改包 |
| adb | 安装、日志、备份测试 |
| Frida + objection | 运行时 Hook、ssl pinning bypass（测防御） |
Android 代理：
adb shell settings put global http_proxy 10.0.2.2:8080
二、动态测试用例库
- 传输：Pinning 开启时，装用户 CA 应无法解密（期望 fail 连接）
- 存储：登录后
adb shell run-as com.app cat shared_prefs/*.xml无明文 token - 会话：注销后旧 Access Token 调 API 返回 401
- Deep Link：
adb shell am start -a android.intent.action.VIEW -d "evil://..."应拒绝 - 后台：App 后台时剪贴板是否仍含一次性密码
DAST 执行环
DAST 执行环
三、SSL Pinning 验证
期望：安全 App 在 Burp CA 下登录失败或证书错误。
若用 Frida 脚本绕过 Pinning 成功抓包 — 说明缺 RASP/完整性检测，记录为 Medium：「Root 环境可 MITM」。
四、iOS DAST 要点
- 需越狱或使用 Corellium 等；生产评估用 TestFlight 包 + 代理
- Keychain 枚举：
objection -g com.app explore→ios keychain dump - ATS 例外域名在 Info.plist 审计
| 工具 | Android | iOS |
|---|---|---|
| 抓包 | Burp + 用户 CA | Burp + 描述文件 |
| Hook | Frida | Frida (越狱) |
| 自动化 | MobSF Dynamic | 较少，偏手工 |
⚠️ 常见坑：在 emulator 关闭 Pinning 测通就认为生产安全 — 需分环境报告。
💡 关键直觉：DAST 证明「攻击者视角下还能不能打穿」——与 SAST 互补。
本章回顾
- 代理 + 改参是 API 逻辑漏洞主手段
- Pinning 验证是 M2 必测项
- Frida 用于验证密钥是否运行时暴露
- 用例库应版本化，随功能增量更新
下一节：逆向分析与漏洞管理闭环。
深化：抓包配置与用例设计
DAST 环境搭建的关键是让模拟器的流量走代理：设置系统代理后，安装 Burp CA 证书到系统信任库（模拟器可 root，直接 push 到系统证书目录），否则 HTTPS 流量无法解密。注意：证书装进「用户」信任库与「系统」信任库不同，Android 7+ 默认应用不信任用户证书，这正是很多 App「明明开了代理却解不了包」的原因。
# 模拟器代理 + 系统 CA（示意） adb shell settings put global http_proxy 10.0.2.2:8080 adb push burp_ca.der /system/etc/security/cacerts/ adb shell chmod 644 /system/etc/security/cacerts/burp_ca.der
动态用例设计要覆盖传输、存储、会话、深链、后台五类，每类都有「期望安全」与「失败信号」。Pinning 验证的期望是「装用户 CA 后连接失败」——能解密说明 Pinning 失效。Frida 用于运行时验证：hook 加密函数看密钥是否暴露、hook 存储读写看是否有明文落盘。工具链只服务于验证目标，别为了用而用。
| 用例类 | 期望 | 失败信号 |
|---|---|---|
| 传输 | Pinning 下解密失败 | 能解密 |
| 存储 | 无明文 token | run-as 可读明文 |
| 会话 | 注销后 401 | 旧 token 有效 |
| 深链 | 拒绝恶意 scheme | 触发跳转 |
动态测试的报告与复现
动态测试的产出是「攻击可复现」的证据，不是「我觉得有漏洞」。每条发现要包含：触发步骤（从安装到复现的完整操作）、请求与响应（抓包记录）、影响说明（能被利用做什么）、修复与复测建议。复现步骤必须别人照做能复现，否则开发无法验证修复。建议维护一份动态用例库，随功能迭代增量更新——新功能上线前跑一遍旧用例，能拦住大量回归性漏洞。
# 复现记录模板 步骤1: 模拟器安装 release 包 步骤2: 登录测试账号，抓包登录接口 步骤3: 修改响应中的余额字段并重放 结果: 客户端显示被篡改金额 -> 客户端信任响应 影响: 展示层可被篡改，需服务端校验
动态测试还有个常见误区：只测「能跑通的路径」。正确做法是同时测异常路径——注销后重放旧 Token、改包后重试、弱网下重复提交，这些路径才是漏洞的高发区。
| 报告要素 | 要求 |
|---|---|
| 触发步骤 | 他人可复现 |
| 证据 | 抓包/截图 |
| 影响 | 可被利用做什么 |
| 复测 | 修复后重跑 |
测试环境的搭建规范
动态测试环境要可复现：固定模拟器镜像版本、固定代理配置、固定 CA 证书、记录测试账号与数据样本。建议写一份环境搭建文档，新成员照着半小时搭完，而不是靠口口相传。环境差异（模拟器与真机、Android 版本、iOS 版本）在报告里注明。可复现的环境是测试结果可信的前提，也是复测能够成立的基础。
用例库的维护
动态用例库是团队资产，要随功能迭代维护：新功能上线补用例，漏洞修复后把复现步骤沉淀为用例，工具升级后回归全部用例。用例库按模块组织，每条含目标、步骤、期望、失败信号。维护用例库的收益是复利式的——每版都跑，回归漏洞在发版前就被拦住。