Apple授权过程的任意账号登录漏洞分析报告

1. 前置知识

1.1 JWT组成

JSON Web Token (JWT)由三部分组成：

• Header：包含算法(alg)和令牌类型(typ)
• Payload：包含声明(claims)如用户信息、过期时间等
• Signature：用于验证消息完整性和真实性

格式：Base64UrlEncode(Header).Base64UrlEncode(Payload).Signature

示例JWT解码后：

{
  "alg": "HS512",
  "typ": "JWT"
}
{
  "iat": 1586525277,
  "admin": "false",
  "user": "Jerry"
}

1.2 Sign in with Apple简介

苹果提供的OAuth 2.0类似授权服务，允许用户使用Apple ID登录第三方应用/网站。

主要特点：

• 隐私保护：可选择隐藏真实邮箱，使用Apple私密邮件中转服务
• 安全性：内置双重认证，支持Face ID/Touch ID
• 强制性：支持其他社交登录的应用必须同时支持Apple登录

用户信息共享：

1. 用户姓名
2. 用户电子邮件地址（可选择真实邮箱或Apple中转邮箱）

2. 漏洞详情

2.1 漏洞发现

• 发现者：Bhavuk Jain (2020年4月)
• 赏金：$100,000 (Apple Security Bounty计划)
• 影响：任意账号接管(account takeover)

2.2 漏洞原理

在授权流程的第2步(Authorization Granted)，攻击者可构造恶意请求：

POST /XXXX/XXXX HTTP/1.1
Host: appleid.apple.com

{"email":"任意邮箱地址"}

漏洞点：

• 仅验证JWT签名，未验证邮箱所有权
• 请求参数过于简单，缺乏nonce等安全参数
• 返回包含该邮箱的有效JWT，导致账号接管

2.3 影响范围

理论上所有集成"Sign in with Apple"的应用，包括：

• Adobe
• TikTok
• Dropbox
• Spotify
• Airbnb
• 微博海外版等

3. 授权流程分析

3.1 正常流程（6步）

1. 授权请求(Authorization Request)
2. 授权授予(Authorization Granted) ← 漏洞所在
3. 访问令牌请求(Access Token Request)
4. 访问令牌响应(Access Token Response)
5. API调用(API Call)
6. 资源响应(Resource Response)

3.2 正常JWT Payload示例

{
  "iss": "https://appleid.apple.com",
  "aud": "com.XXXX.weblogin",
  "exp": 158XXXXXXX,
  "iat": 158XXXXXXX,
  "sub": "XXXX.XXXXX.XXXX",
  "c_hash": "FJXwx9EHQqXXXXXXXX",
  "email": "contact@bhavukjain.com", // 或中转邮箱
  "email_verified": "true",
  "auth_time": 158XXXXXXX,
  "nonce_supported": true
}

4. 修复方案

Apple修复后的授权请求：

POST /appleauth/auth/oauth/authorize HTTP/1.1
Host: appleid.apple.com
... [其他头部信息] ...
Content-Type: application/json

{
  "client": {
    "id": "notion.signin",
    "redirectUri": "https://www.notion.so/applepopupcallback"
  },
  "scopes": [],
  "state": "eyJjYWxsYmFj...",
  "anonymousEmail": true,
  "nonce": "493758775e30f12a539b31bbad9d397792f725c55be255b3",
  "responseMode": "form_post",
  "responseType": "code",
  "email": "yourmail1@icloud.com"
}

关键修复点：

1. 增加nonce参数防止重放攻击
2. 添加encryptedToken增强安全性
3. 完善请求参数校验机制
4. 增加state参数维护会话状态

5. 安全建议

5.1 对OAuth服务提供者的建议

1. 严格验证所有客户端提交的参数
2. 实现完整的OAuth 2.0安全规范
3. 增加关键操作的二次验证
4. 实施完善的日志监控机制

5.2 对第三方应用开发者的建议

1. 实现多因素认证机制
2. 监控异常登录行为
3. 定期审计集成代码
4. 及时更新SDK和依赖库

6. 总结

此漏洞揭示了OAuth实现中的常见问题：

1. 协议实现不完整导致安全缺陷
2. 参数验证不严格引发逻辑漏洞
3. 身份验证与授权分离的风险

核心教训：即使使用标准协议，实现细节中的安全疏漏仍可能导致严重漏洞。安全开发需要全面考虑协议规范的所有方面，并实施深度防御策略。