1.2 特点与挑战

1.2 特点与挑战

本节摘要：移动设备易丢失、网络不可信、Android 碎片化、权限模型复杂、多渠道分发——这些不是「小麻烦」，而是威胁模型里的硬约束。本节对照桌面/Web，帮你在设计评审里拒绝「照搬服务端方案到客户端」。

本节目标

1. 列举七项移动独有挑战及对应设计对策
2. 解释为何公共 Wi-Fi 上 MITM 是默认假设而非极端场景
3. 说明后台运行对会话与密钥生命周期的影响

一、挑战对照表

SOURCE 1.2 列出移动相对传统应用的核心差异：

移动威胁环境示意

移动威胁环境示意

二、深度案例：碎片化如何变成漏洞

同一套 WebView.addJavascriptInterface 在 Android 4.x 曾导致远程代码执行；老系统用户未升级，开发者若未设 minSdkVersion 或未禁用危险接口，等于为攻击者保留时间窗口。挑战不是「测几台旗舰机」，而是：

• CI 矩阵覆盖最低支持版本
• 安全补丁级别（Android Build.VERSION.SECURITY_PATCH）纳入风控

三、网络切换：MITM 是默认假设

移动设备在蜂窝与 Wi-Fi 间漫游。SOURCE 指出：很多公共热点无加密或使用恶意 DNS。对策：

<!-- Android Network Security Config：禁止明文 -->
<network-security-config>
  <base-config cleartextTrafficPermitted="false" />
</network-security-config>
​

iOS 侧 App Transport Security (ATS) 默认要求 HTTPS；NSAllowsArbitraryLoads 需强理由才能在 App Store 过审。

四、后台与生命周期

App 进入后台可能被系统回收，但磁盘上的 Session 不会自动消失。若 Token 无过期、无绑定设备指纹，捡到手机的人可在 App 恢复后继续操作。

⚠️ 常见坑：只在「前台 Activity」做权限检查，后台 Service 仍读通讯录。

💡 关键直觉：移动威胁模型默认设备与网络均不可信——服务端才是信任锚点。

一节小结

• 七大挑战：碎片化、物理访问、网络、资源、权限、分发、生命周期
• MITM 与侧载是高频路径，不是理论威胁
• Network Security Config / ATS 是基线，Pinning 是加强
• 后台被杀 ≠ 会话失效，需显式 Token 策略

下一节用 CIA 与纵深防御把这些挑战收敛成可执行原则。

深化：把挑战翻译成设计约束

七项挑战本质上把威胁模型钉死了：设备可能物理失窃、网络默认不可信、系统版本不齐、资源有限、权限易被滥用、分发渠道多样、生命周期不可控。设计时把它们当作硬约束而不是「小概率事件」。举例：碎片化要求按最低支持版本做矩阵测试，并跟踪安全补丁级别；不可信网络要求 HTTPS 成为硬门槛，Pinning 用于关键业务；后台生命周期要求会话状态与密钥生命周期显式管理。

<!-- 约束落地：Android 明文流量一律禁止 -->
<network-security-config>
  <base-config cleartextTrafficPermitted="false">
    <trust-anchors>
      <certificates src="system" />
    </trust-anchors>
  </base-config>
</network-security-config>
​

把约束写进代码评审清单，比口头强调有效。评审时逐条核对：是否禁明文、是否验证书、Token 是否加密存储、注销是否擦除、后台是否最小化权限调用。

设备丢失场景的完整剧本

设备丢失是移动特有的高概率威胁，值得把整个剧本走一遍：手机被偷后，攻击者可能尝试解锁屏幕、备份数据、导出应用沙箱、在 Root 设备上直接读文件。防线依次是：锁屏与生物识别拖延解锁、全磁盘加密挡住冷启动读取、Keystore/Keychain 让密钥不可导出、远程擦除与账号下线让数据即使被读出也无法使用。任何一环缺失，链条就会断开。测试时请用一台已解锁且 Root 的设备模拟最坏情况，验证「拿到设备能否读到 Token、能否用它调接口」。