【译】不合理的使用OAuth,导致账号被分分钟登录
字数 1513 2025-08-29 08:31:53
OAuth 2.0在移动应用中的安全风险与防御指南
1. 概述
本文档详细分析了移动应用中OAuth 2.0协议实现的安全问题,特别是由于第三方应用开发人员不合理使用OAuth导致的新型攻击手法。攻击者可以远程利用这些漏洞,悄无声息地登录受害者的应用账户。
2. OAuth 2.0在移动平台上的实现流程
2.1 标准流程
- 用户尝试通过IdP登录第三方应用
- 应用通过安全通道将应用信息(包名、签名、请求权限)发送给IdP客户端
- IdP客户端验证应用信息后向IdP服务器发送授权请求
- IdP服务器比较请求信息与预注册信息,若匹配则通过IdP客户端向第三方应用发放access token(AT)
- IdP应用通过安全通道将AT返回给第三方应用
- 第三方应用将AT发送到其后端服务器
- 应用服务器调用IdP提供的SSO-API验证AT
- IdP服务器验证AT有效性后向应用服务器发送授权信息
- 应用服务器通过AT获取用户数据并授权登录
2.2 OpenID Connect协议
OpenID Connect(OIDC)是OAuth 2.0的扩展,用于减少身份验证的请求次数:
- IdP服务器对用户信息进行数字签名
- 签名的用户信息和原始AT一起发送到应用服务器
- 应用服务器可通过签名直接识别用户,无需高延迟API调用
3. 常见的错误实现形式
3.1 不验证用户信息绑定
许多应用服务器仅根据收到的用户信息(如用户ID/邮箱)授权登录,而不验证这些信息是否真的绑定到已发布的OAuth access token。
3.2 忽略签名验证
即使IdP对用户信息进行了数字签名,某些应用也不验证签名,仅从签名中提取用户ID作为身份证明。
3.3 直接从设备获取用户信息
有些应用直接从移动设备获取用户信息,忽视IdP接收到的OAuth token,导致服务器无法验证用户标识符是否绑定到有效的AT。
4. 攻击手法详解
4.1 基本攻击步骤
- 攻击者设置MITM代理监控网络流量
- 安装易受攻击的第三方应用
- 使用自己的IdP账户登录应用
- 在OAuth消息交换过程中,通过MITM代理将受害者用户标识替换为自己的标识
- 应用服务器直接使用被篡改的用户标识授权登录
4.2 绕过证书锁定的方法
- 卸载IdP客户端应用,使OAuth SDK降级使用内置webview浏览器
- 使用SSLUnpinning等工具禁用原生Android框架的证书锁定
- 对IdP客户端应用进行逆向,手动删除证书锁定功能
5. 现实影响
5.1 漏洞普遍性
对使用新浪、Facebook和Google OAuth服务的Top 600 Android应用测试发现:
- 平均41.21%的应用易受此类攻击
- 受影响应用总下载量超过24亿次
- 保守估计超过10亿移动应用账号存在风险
5.2 潜在危害
攻击者可获取:
- 详细旅行行程
- 个人/亲密通信档案
- 家庭/私人照片
- 个人财务记录
- 观看或购物历史
- 操作与账户关联的线上货币
6. 防御建议
6.1 对IdP的建议
- 提供更清晰、侧重安全的OAuth 2.0 SSO API使用指南
- 为每个移动应用发布私有用户标识符,而非全局标识符
- 对第三方应用进行全面的安全测试
6.2 对应用开发者的建议
- 应用服务器不应信任任何来自客户端的信息,即使已签名
- 只信任来自IdP服务器的直接验证信息
- 实现完整的签名验证流程
- 确保所有用户标识符都绑定到有效的access token
7. 结论
OAuth 2.0在移动平台上的实现存在严重安全隐患,主要源于开发人员对协议的理解不足和实现不规范。各方需重新审视SSO实施并采取补救措施,特别是对用户身份验证流程的严格验证。