【译】不合理的使用OAuth,导致账号被分分钟登录
字数 1513 2025-08-29 08:31:53

OAuth 2.0在移动应用中的安全风险与防御指南

1. 概述

本文档详细分析了移动应用中OAuth 2.0协议实现的安全问题,特别是由于第三方应用开发人员不合理使用OAuth导致的新型攻击手法。攻击者可以远程利用这些漏洞,悄无声息地登录受害者的应用账户。

2. OAuth 2.0在移动平台上的实现流程

2.1 标准流程

  1. 用户尝试通过IdP登录第三方应用
  2. 应用通过安全通道将应用信息(包名、签名、请求权限)发送给IdP客户端
  3. IdP客户端验证应用信息后向IdP服务器发送授权请求
  4. IdP服务器比较请求信息与预注册信息,若匹配则通过IdP客户端向第三方应用发放access token(AT)
  5. IdP应用通过安全通道将AT返回给第三方应用
  6. 第三方应用将AT发送到其后端服务器
  7. 应用服务器调用IdP提供的SSO-API验证AT
  8. IdP服务器验证AT有效性后向应用服务器发送授权信息
  9. 应用服务器通过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 基本攻击步骤

  1. 攻击者设置MITM代理监控网络流量
  2. 安装易受攻击的第三方应用
  3. 使用自己的IdP账户登录应用
  4. 在OAuth消息交换过程中,通过MITM代理将受害者用户标识替换为自己的标识
  5. 应用服务器直接使用被篡改的用户标识授权登录

4.2 绕过证书锁定的方法

  1. 卸载IdP客户端应用,使OAuth SDK降级使用内置webview浏览器
  2. 使用SSLUnpinning等工具禁用原生Android框架的证书锁定
  3. 对IdP客户端应用进行逆向,手动删除证书锁定功能

5. 现实影响

5.1 漏洞普遍性

对使用新浪、Facebook和Google OAuth服务的Top 600 Android应用测试发现:

  • 平均41.21%的应用易受此类攻击
  • 受影响应用总下载量超过24亿次
  • 保守估计超过10亿移动应用账号存在风险

5.2 潜在危害

攻击者可获取:

  • 详细旅行行程
  • 个人/亲密通信档案
  • 家庭/私人照片
  • 个人财务记录
  • 观看或购物历史
  • 操作与账户关联的线上货币

6. 防御建议

6.1 对IdP的建议

  1. 提供更清晰、侧重安全的OAuth 2.0 SSO API使用指南
  2. 为每个移动应用发布私有用户标识符,而非全局标识符
  3. 对第三方应用进行全面的安全测试

6.2 对应用开发者的建议

  1. 应用服务器不应信任任何来自客户端的信息,即使已签名
  2. 只信任来自IdP服务器的直接验证信息
  3. 实现完整的签名验证流程
  4. 确保所有用户标识符都绑定到有效的access token

7. 结论

OAuth 2.0在移动平台上的实现存在严重安全隐患,主要源于开发人员对协议的理解不足和实现不规范。各方需重新审视SSO实施并采取补救措施,特别是对用户身份验证流程的严格验证。

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实施并采取补救措施,特别是对用户身份验证流程的严格验证。