WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Safeguard your accounts, promotions, and content

Safeguard your accounts, promotions, and content

SecurityPrivacyDeviceCheckApp AttestSign in with Apple
观看原视频

Highlight

Apple 提供三层安全工具：Sign in with Apple 防账户劫持（自带双因素认证+真实用户检测）、DeviceCheck 防促销滥用（每台设备 2 bit 持久标记）、App Attest 防内容盗用（验证连接服务器的 App 是正版且未被篡改）。

核心内容

你的 App 有用户账户系统。有人用钓鱼网站批量窃取密码，在黑市上售卖。你的用户在其他网站用了相同密码，攻击者拿着泄露的凭证库来撞你的登录接口。

你的 App 有促销活动。新用户首单五折。有人写脚本批量注册假账号，薅完优惠就弃号。

你的 App 有付费内容。有人抓包分析你的 API，写了个第三方客户端绕过付费验证，免费分发。

这三个场景分别对应三类风险：账户风险、促销滥用、内容盗用。Session 给出了 Apple 平台的三把锁。

详细内容

Sign in with Apple：账户安全的第一道防线

（04:42）

Sign in with Apple 自带双因素认证。用户在 Apple 设备上可以用 Face ID 或 Touch ID 重新认证，无需输入密码。

更关键的是首次授权时返回的 realUserStatus 标志。Apple 用设备端私有机器学习模型结合服务端推理，判断用户是真人还是机器人：

let credential: ASAuthorizationAppleIDCredential = // ...
switch credential.realUserStatus {
case .likelyReal:
    // 高置信度真人，无需额外验证
    proceedWithRegistration()
case .unknown, .unsupported:
    // 需要额外挑战（如 CAPTCHA）防止脚本流量
    showAdditionalVerification()
}

关键点：

  • realUserStatus 在客户端即可检查，无需等待服务端验证
  • 平台不支持或返回 unknown 时，建议增加人机验证
  • 2020 年反钓鱼工作组报告：全球钓鱼攻击数量在一年内翻倍

DeviceCheck：每台设备 2 bit 的持久标记

（07:03）

DeviceCheck 允许你在每台 Apple 设备上设置 2 bit 信息（值为 0-3），这些信息：

  • 与设备真实性强绑定
  • 即使设备完全重置后仍可读取
  • 不暴露任何设备标识或用户隐私

两个典型用法：

限制促销兑换次数：

1. 用户首次兑换优惠时，查询 DeviceCheck 的 2 bit 值
2. 如果值为 0（未兑换），允许兑换，并将值设为 1（已兑换）
3. 如果值为 1，拒绝重复兑换
4. 一段时间后（如一年），重置为 0，允许再次兑换

限制单设备注册账号数：

1. 用户注册账号时，查询 DeviceCheck 值
2. 值为 0：允许注册，设为 1
3. 值为 1：允许注册，设为 2
4. 值为 2：允许注册，设为 3
5. 值为 3：拒绝注册（已达上限）

关键点：

  • 2 bit 值由你的服务器通过 Apple 服务器设置和查询
  • 可以按业务需求自由定义每个值的含义
  • 建议定期重置，处理设备转手的情况

App Attest：验证 App 的真实性

（10:04）

App Attest 解决的核心问题：连接到你服务器的客户端，真的是你发布的正版 App 吗？

攻击者可以：

  • 反编译你的 App，修改逻辑后重新打包分发
  • 直接调用你的 API，绕过客户端验证
  • 用自动化工具批量刷接口

App Attest 利用 Secure Enclave 生成加密证明：

  1. App 向设备请求 attestation
  2. Secure Enclave 生成包含 App 身份信息的加密断言
  3. App 将断言发送到你的服务器
  4. 你的服务器验证断言：确认 App 是 App Store 正版、未被修改、运行在真机上
  5. 验证通过后才返回敏感内容

关键点：

  • 支持 iOS 14+ 和 tvOS 15+
  • 每次关键操作前都可以验证
  • 验证完全在服务端完成，无需连接 Apple 服务器
  • 详细的服务端验证流程参考 “Mitigate fraud with App Attest and DeviceCheck” session

三类风险的防护策略

（00:37）

风险类型攻击方式防护工具核心机制
账户劫持密码泄露、钓鱼攻击Sign in with Apple双因素认证 + 真实用户检测
促销滥用批量注册、重复兑换DeviceCheck设备级 2 bit 持久标记
内容盗用逆向工程、API 抓包App AttestSecure Enclave 加密验证

关键点：

  • 三层工具可以独立使用，也可以组合使用
  • Sign in with Apple 和 DeviceCheck 都保护用户隐私，不暴露设备或身份信息
  • App Attest 的验证开销很小，适合每次敏感请求前执行

核心启发

  1. 用 Sign in with Apple 替代自建账户系统。如果你的 App 不需要复杂的账户体系，直接接入 Sign in with Apple。用户不用记密码，你不用担心密码泄露。realUserStatus 还能帮你过滤掉批量注册的机器人。入口 API：ASAuthorizationAppleIDCredential.realUserStatus。

  2. 给新用户优惠加上 DeviceCheck 限制。首单五折、免费试用等促销容易被薅。用 DeviceCheck 的 2 bit 标记记录设备是否已享受过优惠，即使卸载重装、恢复出厂设置也逃不掉。入口 API：DCDevice.current.generateToken() + Apple 服务器查询。

  3. 在内容 API 前加上 App Attest 验证。如果你的 App 提供付费视频、音频、游戏内容，在返回资源 URL 前先验证客户端的 attestation。确保调用者是你发布的正版 App，而不是第三方抓包工具。入口 API：DCAppAttestService.shared.attestKey()。

  4. 组合使用三层工具构建纵深防御。Sign in with Apple 保证登录的人是真人，DeviceCheck 保证每台设备的操作次数受限，App Attest 保证连接你服务器的客户端是正版。三层叠加，攻击成本指数级上升。入口：三个 API 按请求链路顺序部署。

  5. 定期审计账户创建和促销兑换的异常模式。即使有了防护工具，也要监控数据：同一 IP 段批量注册、短时间内大量兑换请求、异常地理位置集中出现。工具防自动化，人工审核防高级攻击。入口：服务端日志 + 异常检测规则。

关联 Session

评论

GitHub Issues · utterances