淮安市建设银行网站首页,自己做网站编程,中国百强城市榜单公布,深圳网站建设 网站设计0x00 前提
最近在测试公司的 oauth 认证方面的问题#xff0c;要再去熟悉一下这块#xff0c;所以把这块写一下。
0x01 OAuth2.0 概念
OAuth是一个关于授权#xff08;authorization#xff09;的开放网络标准#xff0c;目前是最常见最通用的一个授权协议。
什么地方…0x00 前提
最近在测试公司的 oauth 认证方面的问题要再去熟悉一下这块所以把这块写一下。
0x01 OAuth2.0 概念
OAuth是一个关于授权authorization的开放网络标准目前是最常见最通用的一个授权协议。
什么地方是OAuth2.0其实这个东西非常的常见
我们的快捷登录其实都是这个拿这个举例子 那么为什么要用这个呢这个
其实道理很简单我们的网站首先使用这个快捷登录肯定是很方便那么第三方网站和我们网站肯定是不能互相相信对方的不可能将用户信息交给对方保存所以一般情况下OAuth允许用户授予此访问权限而无需将其登录凭据暴露给请求的应用程序。这意味着用户可以选择他们想要共享的数据而不必将其帐户的账号密码交给第三方。
0x02 流程梳理
为了方便理解直接用例子展示首先我们要分清楚各个角色我们简单分出4个部分
resource owner资源拥有者就是用户
resource server资源服务器我们想要快捷登录的的网站 zeo.cool
User Agent指浏览器。
authorization server认证服务器三方授权服务器例如 Google授权服务器服务提供商专门用来处理认证授权的服务器认证成功后向客户端发出访问令牌资源所有者身份验证获取授权。
client_id 这个表示网站后台我们的 zeo.cool的网站后端
在实际中有四种实现方式
授权码模式简化模式密码模式客户端模式
0x03 前提
某一个第三方应用 zeo.cool, 应用先去 Google认证中心进行注册。
提供一个回调地址 https://zeo.cool/oauth_calback
然后会得到
ClientID 888888 这个是我的网站zeo.cool的一个标识符号
ClientsecretID 6666666 这个类似私钥要好好保存绝对不能公开
0x04 令牌模式
在OAuth2.0中最常用的当属授权码模式
授权码模式authorization code是功能最完整、流程最严密的授权模式。它的特点就是通过客户端的后台服务器与服务提供商的认证服务器进行互动。 注意说明步骤(A)、(B)和©的线条在通过用户代理时被分成了两部分。在它们通过用户代理时被分成两部分。
A用户访问客户端客户端将用户引导向认证服务器 客户端申请认证的URI包含以下参数 response_type表示授权类型必选项此处的值固定为code client_id表示客户端的ID必选项 redirect_uri表示重定向URI可选项 scope表示申请的权限范围可选项 state可以指定任意的随机字符串可选项 https://www.google.com/v1/oauth/authorize?response_typecodeclient_id888888redirect_uriCALLBACK_URLscopereadstatedslakf54jlk5li54jB用户选择是否给予客户端授权。
C如用户给予授权Google 认证服务器将用户引导向客户端指定的redirection uri同时加上授权码code。用户点击授权后Google 引导用户访问A步骤中指定的重定向url并带着授权码code和state code表示授权码必选项。该码的有效期应该很短通常设为10分钟客户端只能使用该码一次否则会被授权服务器拒绝。该码与客户端ID和重定向URI是一一对应关系。 state可以指定任意的随机字符串可选项 https://zeo.cool/oauth_calback?codeSplxlOBeZQQYbYS6WxSbIAstatedslakf54jlk5li54jDzeo.cool 后段客户端收到code后通过后台的服务器向认证服务器发送code和redirection uri。zeo.cool带着接收到C步骤中的请求后用授权码发送下面的请求去找Google认证服务器要token grant_type表示使用的授权模式必选项此处的值固定为authorization_code。 code表示上一步获得的授权码必选项。 redirect_uri表示重定向URI必选项且必须与A步骤中的该参数值保持一致。 client_id表示客户端ID必选项。 (服务器后端操作)
https://www.Google.com/v1/oauth/token?client_id888888grant_typeauthorization_codecodeAUTHORIZATION_CODEredirect_uriCALLBACK_URLEGoogle认证服务器验证code和redirection uri确认无误后响应客户端访问令牌access token和刷新令牌refresh token。响应D步骤的数据 access_token表示访问令牌 token_type表示令牌类型该值大小写不敏感 expires_in表示过期时间 refresh_token表示更新令牌 scope表示权限范围 {access_token:sdjlkh13khekj2hjkhd23kjd,token_type:xxx,expires_in:3600,refresh_token:zxfdcsa34323dxccc3,example_parameter:xxxxx}最后我的网站 zeo.cool 就可以拿着 access_token 去找Google 去换取相应的信息了
为什么要先发放授权码再用授权码换令牌
这是因为浏览器转向通常就是一次HTTP 302重定向对于用户是可见的换言之授权码可能会暴露给用户以及用户机器 上的其他程序但由于用户并没有Clientsecret而只有授权码是无法换取到令牌的所以避免了令牌在传输转向过程中被泄 漏的风险。 0x05 令牌模式-攻击面
(1)授权码模式下的安全问题常出现在CSRF攻击
A步骤当中有一个参数是可选的 statestate并放在session中这个是服务端生成的一个随机字符串
然后再在A步骤中的请求中带上stateGoogle返回url带有授权码和state的我们的网站
这个时候需要在在服务器后端会去对比这个state是否一致用来防止csrf攻击
如果没有state就会存在一种攻击手法。
1、hacker先获取自己的code
2、制作一个CSRF页面去做C步骤去让受害者用过自己的cookie去做绑定
3、那么最终就会把受害者的cookie绑定到hacker的账户上
(2) 回调URL校验问题
如果回调校验有问题 like
利用一下绕过的正则的技巧可以把跳转到 hacker.com 这样你的code也一起带过去
就可以利用这个code来做后续的问题
https://www.google.com/v1/oauth/authorize?response_typecodeclient_id888888redirect_uriwww.zeo.coolwww.hacker.com?call_backscopereadstatedslakf54jlk5li54j0x06 简化模式隐式授权模式
简化模式implicit grant type不通过第三方应用程序的服务器
直接在浏览器中向认证服务器申请令牌跳过了授权码这个步骤因此得名。
所有步骤在浏览器中完成令牌对访问者是可见的且客户端不需要认证。 A客户端将用户导向认证服务器。 A步骤中客户端发出的HTTP请求包含以下参数 response_type表示授权类型此处的值固定为token必选项。 client_id表示客户端的ID必选项。 redirect_uri表示重定向的URI可选项。 scope表示权限范围可选项。 state表示客户端的当前状态可以指定任意值认证服务器会原封不动地返回这个值。 https://www.Google.com/authorize?response_typetokenclient_idCLIENT_IDredirect_uriCALLBACK_URLscopereadstatexxxB用户决定是否给予客户端授权。
C假设用户给予授权认证服务器将用户导向客户端指定的重定向URI并在URI的Hash部分包含了访问令牌。 C步骤中认证服务器回应客户端的URI包含以下参数 access_token表示访问令牌必选项。 token_type表示令牌类型该值大小写不敏感必选项。 expires_in表示过期时间单位为秒。如果省略该参数必须其他方式设置过期时间。 scope表示权限范围如果与客户端申请的范围一致此项可省略。 state如果客户端的请求中包含这个参数认证服务器的回应也必须一模一样包含这个参数。 https://www.example.com/callback#access_token ACCESS_TOKENstatexyztoken_typeexampleexpires_in3600statexxx使用场景 适用于所有无Server端配合的应用 如手机/桌面客户端程序、浏览器插件。 基于JavaScript等脚本客户端脚本语言实现的应用。
0x07 简化模式攻击面
简化授权模式下的账户劫持
1那么实际场景就是当state参数不存在的时候可以进行csrf攻击
2伪造redirect_uri提供商没有做好redirect_uri的校验
那我们需要做的是找到受信任的网站下的xss漏洞然后重定向获取劫持access_token在获取到access_token后完整攻击
0x08 密码模式
密码模式Resource Owner Password Credentials Grant中用户向客户端提供自己的用户名和密码。客户端使用这些信息向服务商提供商索要授权。
这种直接使用账号密码的情况极少因为有违背最初的设计。 A用户向客户端提供用户名和密码。
B客户端将用户名和密码发给认证服务器向后者请求令牌。 B步骤中客户端发出的HTTP请求包含以下参数 grant_type表示授权类型此处的值固定为password必选项。 username表示用户名必选项。 password表示用户的密码必选项。 scope表示权限范围可选项。 https://www.google.com/token?grant_typepasswordusernameUSERNAMEpasswordPASSWORDclient_idCLIENT_IDC认证服务器确认无误后向客户端提供访问令牌。 {access_token:df908f890sdf09asd890,token_type:example,expires_in:3600,refresh_token:saf43r243fd34f4fg32g,example_parameter:example_value}0x09 客户端模式
客户端模式Client Credentials Grant指客户端以自己的名义而不是以用户的名义向服务提供商进行认证。严格地说客户端模式并不属于OAuth框架所要解决的问题。在此不做过多解释只了解过程。
这个大多数在微服务的情况下都是后端在自己做授权任务 该模式过程如下
A客户端向认证服务器进行身份认证并要求一个访问令牌。 granttype表示授权类型此处的值固定为client_credentials必选项。 scope表示权限范围可选项。 https://www.example.com/token?grant_typeclient_credentialsB认证服务器确认无误后向客户端提供访问令牌。 {access_token:2YotnFZFEjr1zCsicMWpAA,token_type:example,expires_in:3600,example_parameter:example_value}0x10 总结
攻击面主要是CSRF绑定劫持漏洞还有就是回调URL未校验绕过校验或者配合url跳转绕过啥的
