高级OAuth密钥导致账户接管(ATO)🔥

OAuth基础：原理与重要性

OAuth是一个委托访问框架，允许第三方应用在用户授权下操作，而无需共享密码。OAuth 1.0使用签名，而OAuth 2.0通过依赖TLS和承载令牌简化了流程。

OAuth 2.0特别允许使用外部提供商（如Google、Apple、Facebook）登录客户端应用，而无需在客户端应用中输入电子邮件或密码。这一切都是关于后台的令牌交换。

关键组件：

授权服务器：验证用户身份并颁发令牌的提供商（如Google）
客户端应用：通过OAuth登录的目标网站
授权码：从授权服务器获取的一次性代码，用于交换访问令牌
访问令牌：授予对受保护资源的访问权限，通常使用刷新令牌进行更新
资源服务器：托管用户数据的服务器（如Google的API服务器）

流程涉及从客户端到服务器的重定向和交换。以下是高级ASCII流程图：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


+--------+                                           +---------------+
|        |--(A)------- Authorization Grant --------->|               |
|        |                                           |               |
|        |<-(B)----------- Access Token -------------|               |
|        |               & Refresh Token             |               |
|        |                                           |               |
|        |                            +----------+   |               |
|        |--(C)---- Access Token ---->|          |   |               |
|        |                            |          |   |               |
|        |<-(D)- Protected Resource --| Resource |   | Authorization |
| Client |                            |  Server  |   |     Server    |
|        |--(E)---- Access Token ---->|          |   |               |
|        |                            |          |   |               |
|        |<-(F)- Invalid Token Error -|          |   |               |
|        |                            +----------+   |               |
|        |                                           |               |
|        |--(G)----------- Refresh Token ----------->|               |
|        |                                           |               |
|        |<-(H)----------- Access Token -------------|               |
+--------+           & Optional Refresh Token        +---------------+

后台步骤：

用户在客户端应用上通过OAuth发起登录
客户端应用重定向到授权服务器
授权服务器验证用户身份（如果未登录）并请求同意
用户授予访问权限；授权服务器使用code参数重定向回客户端应用的redirect_uri
客户端应用通过后端请求将code交换为访问令牌
使用访问令牌，客户端应用从资源服务器获取用户数据并登录用户

注意：从渗透测试或漏洞猎手的角度来看，这个流程很容易被滥用，因为如果授权码泄露，它通常可以交换为会话，导致账户接管。配置错误会放大这个问题，这在OAuth漏洞产生高额赏金的漏洞奖励计划中很常见。

关键参数中的秘密！

场景一：CSRF攻击

state参数：可以在第一步设置的参数，可以是cookie或存储在本地存储中

授权服务器在多次重定向后检查第一步发送的state令牌是否与第三步相同

如果我们向受害者发送相同的state参数令牌，攻击将不会成功，因为授权服务器会验证state

但等等，许多应用程序不需要state参数，如果授权服务器不验证它，就允许攻击成功。这可能导致CSRF

场景二：开放重定向

redirect_uri参数：重定向uri参数至关重要 - 它是许多基于重定向的攻击的主要载体

在第二个请求中，授权服务器接收redirect_uri参数，该参数指定服务器将用户重定向到的URL以及授权码

在这种场景中，攻击者将其服务器配置为redirect_uri。当受害者被重定向到那里时，攻击者接收授权码。攻击者然后可以将代码交换为访问/会话令牌，并使用它来接管受害者账户（ATO）

不幸的是，这种攻击在现代应用程序中不太可能成功，因为授权服务器通常根据白名单验证redirect_uri。因此，攻击者必须使用替代技术，通常利用开放重定向或其他向量来泄露授权码

绕过开放重定向的方法：

使用/indexOF：target.com.Attacker.com
假相关：//attacker.com
在@前使用/?：https://attacker.com@target.com，https://attacker.com?@target.com
多行正则表达式：attacker.com%0d%0atarget.com
参数污染：redirect=https://target.com&redirect=https://attacker.com

账户接管(ATO) #1🔥

response_mode参数：可以与其他攻击一起使用。参数的正常值是：query

response的另一个可能值是：fragment

这里的代码出现在URL片段中而不是查询中。由于回调只读取查询，它忽略片段，使代码暴露但未被使用

如果代码放在URL片段中，回调端点很可能不会使用它，我们见过它被利用，例如在Reddit中，Frans Rosen会更改此参数，然后代码将仅出现在URL中未被使用，这非常重要，然后你需要另一个漏洞来泄露URL，这不容易获得，但这里确实有一个很好的漏洞，我认为是XSS，但如果你有其他可以泄露URL的漏洞，你可以接管账户

账户接管(ATO) #2

我们可以使用片段进行攻击

重定向到攻击者域

此重定向必须保留参数；但是，这种行为不能保证。如果response_mode更改为fragment，受害者授权代码将包含在URL片段中

因此，代码不会出现在重定向响应中，但会保留在浏览器中。即使执行跨域重定向，浏览器也不会删除URL片段

CSRF + 开放重定向导致ATO #3

这个场景是两个漏洞导致ATO很容易。首先我在POST身份验证CSRF state中发现开放重定向

在我成功登录后，代码发送到攻击者域。我所做的是将响应模式更改为Fragment，在重定向URI中，我将我的代码从我的Web账户嵌入到目标网站。因此，授权服务器会将受害者重定向到此URL，其中包含查询中的我的代码和state

这重定向到我的网站，然后授权服务器因为我们使用了响应模式fragment

会将受害者代码和其他参数添加到片段中，然后受害者将成功登录我的账户，因为那是我的代码

在受害者被重定向到攻击者URL（在这种情况下是攻击者账户）进行身份验证后，授权代码保留在URL片段中。由于片段在重定向过程中持续存在，攻击者可以泄露代码并将其交换为访问/会话令牌，导致账户接管（ATO）

所有这些漏洞的严重性都是：严重

签名……………

感谢阅读，我希望这有所帮助………………

漏洞赏金 | 渗透测试 | 技术写作 | 信息安全 | 漏洞赏金技巧

高级OAuth安全漏洞导致账户接管实战分析

本文深入解析OAuth协议中的安全漏洞，包括CSRF攻击、开放重定向和响应模式滥用等技术细节，通过多个实际攻击场景展示如何利用这些漏洞实现账户接管，为安全研究人员提供实用的漏洞挖掘思路。