2.1 常见攻击类型
2.1 常见攻击类型
本节摘要：SOURCE 2.1 按攻击意图分四类：数据窃取、恶意软件、钓鱼、MITM。本节问题驱动——每种攻击给出你能在日志/取证里看到的信号，而不是抽象定义。
先说结论
- 描述四类攻击的路径与典型工具（adb、Frida、Ettercap、伪造 App）
- 从 Burp/mitmproxy 流量判断 MITM 是否成功
- 识别恶意软件通过 Overlay 钓鱼的 UI 特征
一、数据窃取 (Data Theft)
路径：物理接触设备 → 备份/Root → 读 SharedPreferences/SQLite/Keychain 导出。
| 信号 | 含义 |
|---|---|
adb backup 可导出应用数据 |
未设 android:allowBackup="false" |
/data/data/<pkg>/shared_prefs 明文 XML |
M1 不安全存储 |
| 越狱设备上 Keychain 可读 | 未用 ThisDeviceOnly 保护级别 |
# 安全测试（自有设备）：检查备份面 adb backup -f backup.ab com.example.app
二、恶意软件 (Malware)
银行木马常请求 Accessibility Service 读屏 + Overlay 盖假登录框。Android 侧检查清单：
- 是否诱导开启无障碍
- 是否请求
SYSTEM_ALERT_WINDOW - 安装来源是否非 Play 商店
iOS 侧恶意配置描述文件较少见，但企业证书侧载仍可能发生。
三、网络钓鱼 (Phishing)
移动钓鱼形态：
- 伪造 App — 图标相似、包名
com.examp1e.bank - Deep Link 劫持 — 恶意 App 注册相同 scheme
- SMS 钓鱼 — 短链跳假 H5 登录
钓鱼攻击路径
钓鱼攻击路径
四、中间人攻击 (MITM)
前提：用户安装恶意 CA、或 App 关闭证书校验（TrustAllCerts）。
SOURCE 2.1.4 要点：
- 未 Pinning 的 HTTPS 在恶意热点上可被解密
- 症状：Burp 能解出 JSON 里的 Token
- 对策：TLS 1.2+、系统信任库 + Certificate Pinning（SPKI 哈希）
// 反模式：生产代码切勿出现 OkHttpClient client = new OkHttpClient.Builder() .hostnameVerifier((h, s) -> true) // 关闭校验 .build();
| 攻击 | 首要控制 | 检测手段 |
|---|---|---|
| 数据窃取 | EncryptedSharedPreferences / Keychain | MobSF 静态扫描 |
| 恶意软件 | 最小权限、Play Protect | 行为沙箱 |
| 钓鱼 | Universal Links + 用户教育 | 包名/签名对比 |
| MITM | Pinning + 禁明文 | Burp + 用户 CA |
⚠️ 常见坑：只测公司 Wi-Fi，未在「用户装 Burp CA」场景下验证 Pinning。
💡 关键直觉：移动攻击常链式组合——MITM 拿 Token + 本地明文存储 = 账号接管。
重点提炼
- 四类攻击各有可观测信号
- 数据窃取根因常在 M1；MITM 根因常在 M2/M5
- 禁用证书校验是 Critical 级缺陷
- 测试必须覆盖备份、侧载、恶意 CA 三类面
下一节系统展开 OWASP Mobile Top 10 条目。
深化：链式攻击与取证信号
单点防御再强，也挡不住链式组合。常见链条：MITM 抓包拿到 Token 之后，若本地明文存储，直接手机取证即可长期接管账号；恶意 App 通过无障碍服务读屏拿到一次性密码，配合钓鱼页面完成转账。因此安全测试要按「攻击链」而不是「单点」来设计用例。
# 取证视角：设备上能拿到什么（自有设备） adb shell "run-as com.example.app ls /data/data/com.example.app/shared_prefs" adb shell "run-as com.example.app cat /data/data/com.example.app/shared_prefs/*.xml" # 输出含明文 token/password 即 M1 命中
攻击检测靠信号：日志里出现大量异常登录是账号接管信号；后台频繁启动摄像头是恶意 App 行为特征；同一账号多设备并发是会话被窃信号。把信号接入风控与告警，比事后分析更有价值。
| 攻击链 | 环节 | 每个环节的防线 |
|---|---|---|
| MITM→Token→越权 | 抓包/解密/重放 | Pinning/短TTL/服务端鉴权 |
| 侧载→重打包→键盘记录 | 下载/签名/注入 | 完整性校验/商店签名 |
| 钓鱼→凭据→转账 | 伪造App/深链/伪造页 | 签名对比/Universal Links |
四类攻击的防御纵深匹配
数据窃取的防御在存储层：能少存就少存，必须存则 Keystore/Keychain 加密，且 allowBackup 关闭。恶意软件的防御在权限与分发层：最小权限声明、Play Protect 或 App Attest 校验安装来源、敏感操作加服务端二次确认。钓鱼的防御在标识与教育：包名签名比对、Universal Links、对「重新登录」类弹窗保持怀疑。MITM 的防御在传输层：TLS 1.2+、系统信任库校验、关键域名 Pinning。四类攻击的防线互不替代，逐一落地才构成完整纵深。
| 攻击 | 主要防线 | 次要防线 |
|---|---|---|
| 数据窃取 | 加密存储 | 禁备份 |
| 恶意软件 | 权限最小化 | 完整性校验 |
| 钓鱼 | Universal Links | 用户教育 |
| MITM | TLS+Pinning | 服务端风控 |
攻击信号的监控落地
把攻击信号接入监控，比事后分析更有价值。设备侧建议上报：异常登录地点、设备指纹变化、Root/Jailbreak 检测结果；服务端建议跟踪：单账号并发设备数、短时多次失败登录、敏感接口的异常调用频率。每条信号都要有对应动作：限流、二次验证、告警、冻结。监控阈值要经过调优，避免噪声淹没真实告警——宁可先粗后细，不要一步到位导致长期无人看。
信号与告警的调优节奏
告警阈值上线后要持续调优：先保守放量，观察真实告警与误报的比例；再逐步收紧，把「明确攻击」与「可疑行为」分开处理。每一条告警都要能回溯到原始日志，否则告警就是噪声。调优记录保留，作为下一次迭代的起点。监控与告警是安全运营的日常，不是发版前的临时动作。