挖洞经验 | 绕过GitHub的OAuth授权验证机制($25000)
字数 1287 2025-08-18 11:39:08

GitHub OAuth授权验证绕过漏洞分析与教学

漏洞概述

本教学文档详细分析GitHub OAuth授权验证机制中的一个高危漏洞,该漏洞允许攻击者绕过正常的OAuth授权流程,无需用户明确授权即可获取用户数据的访问权限。漏洞发现者因此获得了GitHub官方$25,000的奖励。

OAuth授权流程基础

GitHub的标准OAuth授权流程如下:

  1. 第三方应用("Foo App")向用户发送包含查询信息的授权链接:

    https://github.com/login/oauth/authorize
    
  2. 用户访问该链接后,GitHub显示授权页面,询问用户是否允许该应用访问其数据

  3. 用户点击"Authorize"按钮后:

    • 发送包含CSRF token的POST请求
    • GitHub验证CSRF token后授予权限
    • 跳转回第三方应用并附带授权码

漏洞技术细节

授权端点实现

GitHub使用Ruby on Rails框架实现OAuth授权端点:

# 路由配置
match "/login/oauth/authorize", 
  :to => "[the controller]", # 所有请求都发送到同一控制器
  :via => [:get, :post]      # 接受GET和POST请求

# 控制器逻辑
if request.get?
  # 显示授权页面HTML
else
  # 授予应用权限
end

Rails路由的特殊行为

漏洞的核心在于Rails框架对HTTP HEAD请求的特殊处理:

  1. HEAD请求定义:HEAD方法与GET相同,但服务器不返回消息体,仅返回响应头
  2. Rails的路由处理:Rails会将HEAD请求路由到与GET请求相同的控制器
  3. 控制器检测:控制器使用request.get?检查请求类型时,HEAD请求会返回false

漏洞利用原理

攻击者可构造以下攻击链:

  1. https://github.com/login/oauth/authorize?发送HEAD请求
  2. Rails路由将其视为GET请求路由到控制器
  3. 控制器检查请求类型:
    • request.get?返回false(因为是HEAD请求)
    • 控制器认为这是授权请求(POST逻辑)
  4. GitHub跳过CSRF验证(HEAD请求通常不需要CSRF防护)
  5. 最终授予攻击者指定的OAuth权限

漏洞影响

成功利用此漏洞可导致:

  • 无需用户交互即可获取OAuth访问权限
  • 读取或修改用户敏感数据
  • 完全绕过GitHub的授权确认页面

防御措施

GitHub在收到报告后3小时内修复了该漏洞,主要修复方法包括:

  1. 显式检查请求方法,不仅依赖request.get?
  2. 对授权操作强制要求CSRF验证,无论请求方法为何
  3. 限制OAuth授权端点仅接受GET和POST方法

教学要点总结

  1. HTTP方法处理:理解不同HTTP方法(GET/POST/HEAD)的语义差异
  2. 框架特性:深入了解所用框架的特殊行为(如Rails的HEAD请求路由)
  3. 逻辑边界测试:测试不同请求方法对同一端点的访问
  4. CSRF防护:确保所有状态修改操作都受到CSRF保护
  5. 输入验证:显式验证请求方法而不仅依赖框架默认行为

漏洞挖掘方法论

  1. 逆向分析:反混淆企业版代码寻找异常行为
  2. 流程跟踪:完整跟踪关键业务流程(如OAuth授权)
  3. 边界测试:测试非标准输入(如非常规HTTP方法)
  4. 框架研究:深入研究所用框架的特殊行为和潜在陷阱

此漏洞案例展示了深入研究框架特性和全面测试所有可能的输入方法的重要性,即使是看似无害的HEAD请求也可能导致严重的安全问题。

GitHub OAuth授权验证绕过漏洞分析与教学 漏洞概述 本教学文档详细分析GitHub OAuth授权验证机制中的一个高危漏洞,该漏洞允许攻击者绕过正常的OAuth授权流程,无需用户明确授权即可获取用户数据的访问权限。漏洞发现者因此获得了GitHub官方$25,000的奖励。 OAuth授权流程基础 GitHub的标准OAuth授权流程如下: 第三方应用("Foo App")向用户发送包含查询信息的授权链接: 用户访问该链接后,GitHub显示授权页面,询问用户是否允许该应用访问其数据 用户点击"Authorize"按钮后: 发送包含CSRF token的POST请求 GitHub验证CSRF token后授予权限 跳转回第三方应用并附带授权码 漏洞技术细节 授权端点实现 GitHub使用Ruby on Rails框架实现OAuth授权端点: Rails路由的特殊行为 漏洞的核心在于Rails框架对HTTP HEAD请求的特殊处理: HEAD请求定义 :HEAD方法与GET相同,但服务器不返回消息体,仅返回响应头 Rails的路由处理 :Rails会将HEAD请求路由到与GET请求相同的控制器 控制器检测 :控制器使用 request.get? 检查请求类型时,HEAD请求会返回 false 漏洞利用原理 攻击者可构造以下攻击链: 向 https://github.com/login/oauth/authorize? 发送HEAD请求 Rails路由将其视为GET请求路由到控制器 控制器检查请求类型: request.get? 返回 false (因为是HEAD请求) 控制器认为这是授权请求(POST逻辑) GitHub跳过CSRF验证(HEAD请求通常不需要CSRF防护) 最终授予攻击者指定的OAuth权限 漏洞影响 成功利用此漏洞可导致: 无需用户交互即可获取OAuth访问权限 读取或修改用户敏感数据 完全绕过GitHub的授权确认页面 防御措施 GitHub在收到报告后3小时内修复了该漏洞,主要修复方法包括: 显式检查请求方法,不仅依赖 request.get? 对授权操作强制要求CSRF验证,无论请求方法为何 限制OAuth授权端点仅接受GET和POST方法 教学要点总结 HTTP方法处理 :理解不同HTTP方法(GET/POST/HEAD)的语义差异 框架特性 :深入了解所用框架的特殊行为(如Rails的HEAD请求路由) 逻辑边界测试 :测试不同请求方法对同一端点的访问 CSRF防护 :确保所有状态修改操作都受到CSRF保护 输入验证 :显式验证请求方法而不仅依赖框架默认行为 漏洞挖掘方法论 逆向分析 :反混淆企业版代码寻找异常行为 流程跟踪 :完整跟踪关键业务流程(如OAuth授权) 边界测试 :测试非标准输入(如非常规HTTP方法) 框架研究 :深入研究所用框架的特殊行为和潜在陷阱 此漏洞案例展示了深入研究框架特性和全面测试所有可能的输入方法的重要性,即使是看似无害的HEAD请求也可能导致严重的安全问题。