这里写自定义目录标题
一、OAuth2.0介绍
OAuth 是一种常用的授权框架，它使网站和 Web 应用程序能够请求对另一个应用程序上的用户帐户进行有限访问。
1.1 两种类型
OAuth2.0框架有两种授权类型：分别是授权码授权和隐式授权
1、授权码授权客户端应用程序向OAuth服务请求数据时询问用户是否同意该请求的访问，当用户接受后，客户端会收到OAuth服务发来的授权code；而后客户端应用程序与OAuth服务之间交换此code来接受“访问令牌”，在获取相关用户数据的时候就使用“访问令牌”进行。
2、隐式授权比授权码授权简单，客户端应用程序不需要通过授权code去交换“访问令牌”，是在用户同意后立即接受“访问令牌”，安全性比授权码授权类型差。
1.2 三个角色
这里的3个角色指的就是上述图中所展现出来的3个通信角色
1、客户端应用程序：想要访问用户数据的网站或Web应用程序
2、资源所有者：客户端应用程序想要访问其数据的用户（注意是用户）
3、OAuth服务提供商：控制用户数据及其访问权限的网站或应用程序。它们通过提供用于与授权服务器和自愿服务器交互的API来支持OAuth
1.3 四个阶段
阶段1：客户端应用程序请求访问用户数据的子集，指定他们想要使用哪种授权类型以及他们想要什么样的访问权限。
阶段2：系统会提示用户登录 OAuth 服务并明确同意所请求的访问。
阶段3：客户端应用程序会收到一个唯一的访问令牌，以证明他们有权从用户那里访问所请求的数据。 这究竟是如何发生的，取决于资助类型。
阶段4：客户端应用程序使用此访问令牌进行 API 调用，以从资源服务器获取相关数据。
二、Lab-1（Authentication bypass via OAuth implicit flow）
2.1 产生原理
隐式授权通过浏览器发送访问令牌，访问令牌作为 URL 片段从 OAuth 服务通过用户浏览器发送到客户端应用程序。 然后客户端应用程序使用 JavaScript 访问令牌。 麻烦的是，如果应用程序想要在用户关闭页面后保持会话，它需要将当前用户数据（通常是用户 ID 和访问令牌）存储在某处。
如果在客户端没有对访问令牌与请求中其他数据匹配，则可导致修改服务器可能判断的键值而访问到其他人的资源
2.2 利用过程
先准备好环境（burpsuite抓包+靶场页面）
进行登录并实时查看HTTP history（开启抓包）
在history中看到OAuth服务返回的数据包中存在邮箱这一关键键值（可唯一标识该用户）
再看紧接着的下一个数据包，客户端将接收到的用户信息作为post数据发送给OAuth服务以请求资源
根据任务提示这里修改数据包的email值为carlos@carlos-montoya.net，可请求到carlos用户的资源
2.3 加固修复
此情况很难单方面在客户端进行修复
三、Lab-2（Forced OAuth profile linking）
2.1 产生原理
客户端在发送认证请求时候没用加入state属性而导致不确定返回包是否是同一个人发出，如果存在state属性，服务器会将state属性及值不变地返回给客户端进行验证
2.2 利用过程
开启代理并登陆
附加社交资料
查看HTTP history看到 有个请求认证的数据包中缺少state属性，那考试这里是否存在类似于csrf的攻击呢？（state属性作用请看前面部分）
再次点击附加社交资料并抓包复制其URL后将该请求包Drop掉
退出博客后进入漏洞利用服务器
这里使用iframe标签，当攻击者访问时自动请求标签src指向的url地址，确定无误后依次点击store 和 Deliver exploit to victim
重新尝试登陆，注意这里选择使用社交媒体登陆
已经成为admin权限了，完成通关只需进入Admin panel删除carlos
PS：这个过程我做第二次查看数据包才清楚，简单解释一下：当点击附加社交资料时，客户端向服务器发送了一次认证（缺少state值但这里不重要），请求到了一个oauth-linking?code=xxxxx的资源链接，这个code应该是在服务端已经标识了我的用户名或客户端，所以当我把这个链接发送给受害者时，受害者就将自己的社交资料绑定给了我，进而我获取到了admin权限；重要的是根据安全性要求，客户端应该在每次与OAuth服务进行通信时都带上state参数，该参数作为客户端应用程序和OAuth服务之间来回传递的CSRF TOKEN，以增强安全通信
2.3 加固修复
在与OAuth服务进行通信时url带上一个不可被猜测到的值的state属性
四、Lab-3（OAuth account hijacking via redirect_uri）
这一关比较有意思和经典
2.1 产生原理
OAuth服务端收到redirect_uri后未对其进行校验，进而攻击者可将uri改为自己的站点后发送给受害者访问，导致返回的code发送到了攻击者的站点，使其获取到了受害者资源标识
2.2 利用过程
上才艺：burpsuite+浏览器抓包，先使用wiener:peter进行登录后注销（根据实验室步骤）
再次点击我的账户并开启Burpsuite拦截，当出现这个数据包的时候我们可以对redirect_uri进行测试
放入Repeater，直接Go，正常返回code是意料之中
此时修改uri看任然返回code，说明OAuth服务并没有对返回uri进行白名单限制
下面将该请求包Drop后到漏洞利用服务器构造POC发送给受害者（admin）
然后查看访问日志看刚才那个漏洞是否利用生效，日志中看到成功获取到受害者code
下面重复刚才登陆时的抓包动作，在这个地方替换code后放包就可以登陆到admin账户了（如果不行多试几次）
2.3 加固修复
在OAuth服务端收到redirect_uri时验证其是否在白名单内