文章总结： 本文详细分析了OAuth授权流程中六种高危攻击手法：重定向URI篡改可截获授权码直接盗号；CSRF因state参数缺失导致账号绑定劫持；授权码拦截通过流量嗅探窃取临时票据；访问令牌泄露因存储不当或隐式模式引发长期风险；刷新令牌滥用允许攻击者永久维持访问权限；逻辑漏洞可能直接导致账户接管。文档针对每种攻击提供了具体防御方案，包括严格校验redirect_uri、强制PKCE机制、使用HttpOnlyCookie、实施令牌轮换及会话绑定等关键技术措施。 综合评分： 82 文章分类： WEB安全,渗透测试,漏洞分析,安全开发,实战经验

OAuth攻击利用

原创

一个努力的学渣 一个努力的学渣

一个努力的学渣

2026年4月2日 13:01 北京

在小说阅读器读本章

去阅读

免责声明

本文只做学术研究使用，不可对真实未授权网站使用，如若非法他用，与平台和本文作者无关，需自行负责！

正常流程(漏洞就出现在这些环节)

1. 购物 APP 把你推到微信登录页
2. 你同意授权
3. 微信给购物 APP 一张**“临时票据” (Authorization Code)**
4. 购物 APP 拿着票据找微信换**“正式门卡” (Access Token)**
5. 购物 APP 拿着门卡去取头像

重定向 URI 篡改 (Redirect URI Tampering)

🔴 危险等级：极高 (直接丢账号)

• 原理：微信发完“临时票据”后，需要把用户送回购物 APP。这个“送回地址”叫 redirect_uri。如果微信不检查这个地址是不是购物 APP 注册的，黑客就能改成自己的地址，从而截获票据

• 攻击条件：

• 授权服务器（微信）允许客户端随便填回调地址

• 或者白名单校验不严格（比如允许 *.example.com，黑客用 evil.example.com 绕过）

• 存在字符解析差异（如 %00, #, ?, @ 等绕过技巧）

• 攻击模式：

• 授权码模式 (最常见)

• 隐式模式 (旧版)

• 关联参数：

• redirect_uri (回调地址)

• client_id (客户端 ID)

• 攻击过程：(模拟案例：某电商平台劫持)

• 场景： 假设有一个电商平台 Shop.com，接入了微信登录

• 步骤 1：信息收集

  攻击者注册成为 Shop.com 的开发者，或者通过查看网页源代码，获取了该应用的 client_id (例如 APP123)

• 步骤 2：构造恶意链接

  攻击者搭建自己的服务器 Attacker.com，并构造一个特殊的授权链接： https://wechat.com/oauth/authorize?client_id=APP123&redirect_uri=https://Attacker.com/steal&response_type=code (关键点：攻击者将回调地址改成了自己的服务器)

• 步骤 3：诱导用户

  攻击者通过钓鱼邮件发送链接：“点击领取 100 元购物券”

• 步骤 4：用户授权

  受害者点击链接，跳转到真实的微信登录页 (wechat.com)。受害者看到是官方微信页面，输入密码并点击“同意”

• 步骤 5：票据劫持

  微信验证通过后，会根据链接中的 redirect_uri 进行跳转。因为服务器校验疏忽，微信将用户重定向到了： https://Attacker.com/steal?code=XYZ123456 攻击者的服务器自动记录下了 URL 中的 code=XYZ123456

• 步骤 6：换取令牌

  攻击者在后台使用这个 code 和自己的 client_secret，向微信服务器请求换取 Access Token

• 步骤 7：后果

  攻击者获得 Token，冒充受害者登录 Shop.com，查看订单、地址，甚至利用保存的信用卡信息消费

• 防御：

• 精确匹配： 授权服务器必须严格核对 redirect_uri，必须和注册的一模一样（连 / 都不能差）

• 白名单： 只允许预先注册过的地址，禁止动态输入

• 禁用通配符： 尽量避免使用 *.example.com，如果必须使用，需确保子域名不可控风险低

跨站请求伪造 (CSRF / State 参数缺失)

🟠 危险等级：高 (账号被绑定给黑客)

• 原理：OAuth 流程中有一个参数叫 state，用来标记“这次登录是谁发起的”。如果购物网站不检查这个参数，黑客就能把自己的登录状态“嫁接”到受害者身上

• 攻击条件：

• 客户端发起请求时没生成 state 参数

• 客户端收到回调时没校验 state 参数

• 网站使用 OAuth 进行账号绑定或登录

• 攻击模式：所有涉及用户登录的模式

• 关联参数：state (状态参数)

• 攻击过程：(模拟案例：账号绑定劫持)

• 场景： 假设有一个社交平台 Social.com，允许绑定微信

• 步骤 1：黑客发起请求

  黑客登录自己的 Social.com 账号，点击“绑定微信”。平台生成一个状态标记 state=ABC，发给微信

• 步骤 2：构造陷阱

  黑客复制这个绑定链接，发给受害者： https://Social.com/bind/wechat?state=ABC

• 步骤 3：受害者授权

  受害者点击链接，登录受害者自己的微信，并同意授权。微信回调社交平台： https://Social.com/callback?code=VICTIM_CODE&state=ABC

• 步骤 4：验证缺失

  社交平台收到回调，检查 state=ABC，发现匹配。但平台不知道，这个请求最初是黑客发起的

• 步骤 5：绑定错误

  社交平台用 VICTIM_CODE 换来 Token，发现对应的微信用户是受害者。于是，它将受害者的微信绑定到了黑客的社交平台账号上

• 步骤 6：后果

  黑客直接登录自己的社交平台账号，却发现里面全是受害者的私信和好友列表。受害者自己的账号再也登不上去了

• 防御：

• 强制 State： 每次登录请求必须生成一个随机、不可预测的字符串作为 state

• 严格校验： 回调回来时，必须检查 state 是否和刚才发出去的一样

• 会话绑定： 把 state 和用户的本地 Session ID 或 Cookie 绑定

授权码拦截 (Authorization Code Interception)

🔴 危险等级：高 (票据在半路被抢)

• 原理：“临时票据”(Code) 是通过浏览器地址栏传输的。如果这时候没有额外的保护（PKCE），黑客在半路截胡了这个票据，就能换成 Token

• 攻击条件：

• 没有使用 HTTPS (流量明文)

• 手机 App 或前端应用没有使用 PKCE 机制

• 受害者连接了不安全的公共 Wi-Fi 或设备存在恶意软件

• 攻击模式：授权码模式 (特别是公共客户端，如 App、小程序)

• 关联参数：

• code (授权码)

• code_verifier / code_challenge (PKCE 参数)

• 攻击过程：(模拟案例：公共 Wi-Fi 嗅探)

• 场景： 假设有一个旅游 App TravelApp，未启用 PKCE

• 步骤 1：环境搭建

  攻击者在咖啡馆搭建一个名为”Free WiFi”的热点，并部署了流量嗅探工具（如 Wireshark 等理论工具）

• 步骤 2：用户连接

  受害者连接 Wi-Fi，打开 TravelApp，点击“微信登录”

• 步骤 3：流量嗅探

  微信授权成功后，跳转回 App 的链接是 travelapp://callback?code=SECRET_CODE。 由于未启用 PKCE 且通信可能存在漏洞，攻击者通过嗅探工具看到了这个跳转请求中的 code

• 步骤 4：换取令牌

  攻击者立刻向微信服务器发送请求：“我要用这个 Code 换 Token”

• 步骤 5：漏洞利用

  如果 App 没用 PKCE，微信服务器只验证 Code 对不对，就给了攻击者 Token。 (如果有 PKCE 会怎样？微信会问：“请提供这个 Code 对应的密码 (Verifier)”。攻击者只有 Code 没有密码，换不到 Token。)

• 步骤 6：后果

  攻击者拿到了 Token，冒充受害者查看旅游订单，甚至获取位置信息

• 防御：

• 强制 HTTPS： 所有传输必须加密

• 强制 PKCE： 2026 年标准规定，所有应用都必须用 PKCE。相当于给票据加了一把锁，只有发起请求的客户端才有钥匙

• 强制 PKCE： 2026 年标准规定，所有应用都必须用 PKCE。相当于给票据加了一把锁，只有发起请求的客户端才有钥匙

访问令牌泄露 (Access Token Leakage)

🟠 危险等级：高 (门卡被复制)

• 原理：“正式门卡”(Access Token) 是访问资源的凭证。如果这张卡被存在了不安全的地方，或者有效期太长，一旦泄露，攻击者就能一直用

• 攻击条件：

• 使用旧版的“隐式模式”（Token 直接放在 URL 里）

• 前端把 Token 存在 localStorage（容易被 XSS 攻击读取）

• Token 有效期设置过长（如 1 年）

• 日志系统记录了包含 Token 的 URL

• 攻击模式：

• 隐式模式 (高危)

• 授权码模式 (若存储不当)

• 关联参数：

• access_token

• Authorization 头

• 攻击过程：(模拟案例：XSS 窃取令牌)

• 场景： 假设某社交网站 SocialNet 将 Token 存储在 localStorage

• 步骤 1：

  漏洞存在 SocialNet 把 Token 存在了浏览器的 localStorage 里，而且没设过期时间

• 步骤 2：XSS 攻击

  攻击者在该网站的评论区留下了一段恶意代码（比如 ）

• 步骤 3：自动窃取

  受害者访问该评论区时，浏览器自动执行恶意脚本。脚本读取 localStorage 里的 Token，并悄悄发送给攻击者的服务器

• 步骤 4：长期使用

  攻击者拿到 Token 后，因为 Token 有效期很长，他在未来几个月内都可以冒充受害者访问 API，发私信、看隐私照片

• 步骤 5：后果

  用户数据长期泄露，且用户毫无察觉

• 防御：

• 不用隐式模式： 千万别让 Token 出现在 URL 里

• HttpOnly Cookie： 把 Token 存在 Cookie 里，并设为 HttpOnly，这样 JavaScript 脚本就读不到了

• 短有效期： Token 有效期设短点（如 1 小时），配合刷新令牌使用

• 使用 DPoP： 2026 年推荐技术，Token 必须配合密钥使用，即使被偷了，攻击者没密钥也用不了

• 日志脱敏： 确保服务器日志不记录 URL 中的敏感参数

刷新令牌滥用 (Refresh Token Abuse)

🟡 危险等级：中 (永久通行证被盗)

• 原理：Access Token 过期后，需要用 Refresh Token 换新的。Refresh Token 有效期很长。如果它被偷了，且服务器不检查，攻击者就能无限期地换新卡

• 攻击条件：

• Refresh Token 永久有效

• 没有实施“令牌轮换”机制

• Refresh Token 未绑定设备指纹

• 攻击模式：所有使用 Refresh Token 的模式

• 关联参数：refresh_token

• 攻击过程： (模拟案例：数据库泄露后的持久化)

• 场景： 假设某网站数据库被拖库

• 步骤 1：窃取

  攻击者拿到了用户的 refresh_token

• 步骤 2：无限续杯

  Access Token 过期了？攻击者用 refresh_token 换一个新的。又过期了？再换一个新的

• 步骤 3：无法阻断

  即使用户改了密码，如果服务器没撤销这个 refresh_token，攻击者依然能换到新卡

• 步骤 4：后果

  攻击者拥有了永久访问权，除非用户注销所有登录设备。这就像攻击者配了一把万能钥匙，你换了门锁芯，他还能开

• 防御：

• 令牌轮换 (Rotation)： 每次用 Refresh Token 换新卡时，服务器同时发一个新的 Refresh Token，并把旧的作废

• 重用检测： 如果攻击者拿着旧的 Refresh Token 来换，服务器发现“这个旧家伙已经用过啦！”，立刻判定泄露，撤销所有权限并报警

• 绑定设备： Refresh Token 只能在哪台设备上用，换设备就失效

逻辑漏洞导致的账户接管 (Account Takeover)

🔴 危险等级：极高 (直接接管账号)

• 原理：这是 OAuth 实现逻辑中最严重的漏洞之一。当用户尝试将第三方账号（如微信）绑定到现有平台账号时，服务器必须验证**“当前发起绑定的会话”与“完成绑定的回调请求”**是否属于同一用户。如果服务器只验证了第三方回调的有效性，而忽略了当前登录态的一致性，攻击者就可以完成“偷梁换柱”

• 攻击条件：

• 平台支持第三方账号绑定功能

• 绑定回调接口未校验 state 参数，或未校验当前登录 Session 与发起绑定时的 Session 是否一致

• 绑定请求可以被重放

• 攻击模式：所有涉及第三方账号绑定的场景 (OIDC/OAuth)

• 关联参数：

• code (授权码)

• state (状态参数，若缺失则高危)

• session_id / Cookie (当前登录态)

• 攻击过程：(模拟案例：绑定劫持)

• 场景： 某平台 Target.com 允许绑定微信。攻击者想将自己的微信绑定到受害者的平台账号上，或者利用漏洞混淆绑定关系

• 步骤 1：准备账号

  攻击者准备两个浏览器环境（或无痕模式）：

• 浏览器 1： 登录受害者账号 账号 A

• 浏览器 2： 登录攻击者账号 账号 B

• 步骤 2：发起绑定

  (账号 A) 在 浏览器 1 (账号 A) 中，点击“绑定微信”。跳转微信授权页，同意授权。 微信回调回 Target.com 的瞬间，攻击者使用抓包工具（如 Burp Suite）拦截了这个最终的绑定请求数据包

• 数据包内容示例：POST /bind/callback?code=WX_CODE_A&state=XYZ

• 步骤 3：中断流程

  攻击者将拦截到的数据包发送到 Repeater (重放器)，然后 Drop (丢弃) 原始请求

• 此时，账号 A 的页面显示“绑定中…”或超时，实际上绑定未完成

• 步骤 4：切换身份

  (账号 B) 攻击者切换到 浏览器 2 (账号 B)，确保当前登录状态是账号 B

• 步骤 5：重放请求

  在 浏览器 2 中，直接访问或重放刚才拦截到的 账号 A 的绑定回调请求 (POST /bind/callback?code=WX_CODE_A…)

• 注意：此时 Cookie 是账号 B 的登录态，但请求参数是账号 A 发起的授权码

• 步骤 6：观察结果

  检查 账号 B 的绑定设置页面

• 存在漏洞： 如果账号 B 显示“已绑定微信”，说明服务器只认 code，没认当前登录的人是谁。攻击者成功将原本属于 A 流程的微信账号绑定到了 B 上，或者导致 A 无法绑定，B 却莫名绑定了

• 更安全的情况： 如果提示“状态过期”或“会话不匹配”，则防御有效

• 步骤 7：后果

  攻击者可以通过控制第三方账号，接管平台账号 B，或者导致账号 A 无法找回（如果平台仅支持第三方登录）

• 防御：

• Session 绑定： 服务器必须记录发起绑定请求时的 Session ID，在回调时校验当前登录用户的 Session ID 是否一致

• 强制 State 校验： state 参数必须包含用户会话信息，且在回调时严格比对

• 一次性 Token： 绑定流程中的授权码只能使用一次，且与发起绑定的用户 ID 强绑定

范围升级攻击 (Scope Escalation)

🟠 危险等级：高 (权限越界)

• 原理：OAuth 允许客户端请求特定的权限范围（scope），例如“只读头像”或“读写邮件”。如果授权服务器未严格校验客户端请求的 scope 是否超过了其注册时允许的范围，或者用户误点了更高权限，攻击者可以诱导用户授权更高权限，从而获取敏感数据或操作权限

• 攻击条件：

• 授权服务器未校验请求的 scope 是否在客户端注册的白名单内

• 用户界面未清晰展示权限差异，诱导用户点击

• 客户端恶意构造请求

• 攻击模式：所有授权模式 (授权码、隐式等)

• 关联参数：scope (权限范围参数)

• 攻击过程：(模拟案例：从只读到读写)

• 场景： 某邮件客户端 MailApp 注册时只申请了 read_email (读邮件) 权限

• 步骤 1：侦察

  攻击者发现 MailApp 的授权链接格式：https://oauth.com/authorize?client_id=123&scope=read_email

• 步骤 2：构造恶意链接

  攻击者修改 scope 参数，尝试添加更高权限，如 write_email (写邮件) 或 delete_email (删邮件)： https://oauth.com/authorize?client_id=123&scope=read_email write_email

• 步骤 3：诱导授权

  攻击者将该链接发送给受害者，谎称是“升级功能”或“重新登录”

• 步骤 4：服务器校验缺失

  受害者点击链接并授权。如果授权服务器未检查 client_id=123 是否被允许请求 write_email，直接颁发了包含 write_email 的 Token

• 步骤 5：越权操作

  攻击者利用获得的 Token，调用发送邮件 API，以受害者名义发送钓鱼邮件

• 步骤 6：后果

  用户隐私泄露，或被利用发送垃圾邮件，导致账号被封禁

• 防御：

• 服务端白名单校验： 授权服务器必须比对“请求的 Scope”与“客户端注册时允许的 Scope”，只颁发交集部分的权限

• 用户明确知情： 授权页面必须高亮显示敏感权限（如“允许发送邮件”），并要求用户二次确认

• 最小权限原则： 客户端只请求业务真正需要的最小权限

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：一个努力的学渣 一个努力的学渣 一个努力的学渣《OAuth攻击利用》