How we escalated a DOM XSS to a sophisticated 1-click Account Takeover for $8000 – Part 1

I. Introduction 一、引言

Today Frog Sec Team will dive into a fascinating case study where we escalated a seemingly simple DOM XSS into a sophisticated 1-click Account Takeover.
今天，Frog Sec 团队将深入探讨一个引人入胜的案例研究，我们将一个看似简单的 DOM XSS 升级为复杂的一键式帐户接管。

This attack allows the attacker to send a legitimate login link from the application’s email. When the victims (whether unauthenticated or authenticated) clicks on the link from their email, the attacker will be able to compromised the accounts.
此攻击允许攻击者从应用程序的电子邮件发送合法的登录链接。当受害者（无论是未经身份验证的还是经过身份验证的）点击其电子邮件中的链接时，攻击者将能够破坏帐户。

We will take you through our thought process, the obstacles we encountered, and how we overcame them to execute this full chain exploit.
我们将带您了解我们的思维过程、我们遇到的障碍，以及我们如何克服这些障碍来执行这个完整的链条漏洞。

Because this is quite a long read, we will split this blog post into 2 parts:
因为这是一篇很长的读物，我们将这篇博文分为两部分：

• Part 1: Understanding the OAuth login flow and the initial attack surface
  第 1 部分：了解 OAuth 登录流和初始攻击面
• Part 2: Exploiting the DOM XSS and escalating it to a 1-click Account Takeover
  第 2 部分：利用 DOM XSS 并将其升级为一键式帐户接管

Let’s goooo 😤😤😤 让我们咕噜咕噜 😤😤😤

II. Understanding the OAuth login flow and the text-book OAuth attack
二、了解OAuth登录流程和教科书上的OAuth攻击

It would have been impossible to find this vulnerability if we hadn’t understood deeply about the underlying architecture and potential attack vectors of the system.
如果我们没有深入了解系统的底层架构和潜在的攻击媒介，就不可能发现这个漏洞。
Let’s first have a clear understanding of the target.
我们先对目标有一个清晰的认识。

We will refer the target as account.redacted.com and their partner sites as account.partner.com because we didn’t have the permission to disclose the program’s name.
我们将目标 account.redacted.com 称为及其合作伙伴网站， account.partner.com 因为我们无权披露该计划的名称。

1. Investigating the login flow of the application 👀
1. 调查应用程序👀的登录流程

Out of all functionalities, we chose to test for the login flow first because this might be where the High/Critical vulnerabilities are hidden from plain sight.
在所有功能中，我们选择首先测试登录流程，因为这可能是高/严重漏洞隐藏在众目睽睽之下的地方。

account.redacted.com will have a Single Sign On (SSO) portal where other partner sites will integrate this portal to log the users in their services.
account.redacted.com 将具有单点登录 （SSO） 门户，其他合作伙伴站点将在其中集成此门户以将用户登录其服务。

Here is the sequence diagram of the complete OAuth flow:
以下是完整 OAuth 流的序列图：

1. The user will click login to account.partner.com
   用户将单击登录到 account.partner.com

2,3. account.partner.com will generate and return the code_verifier through the xxxxx-pkce cookie and redirect the browser to https://account.redacted.com/authorize with the redirect_uri parameter
2,3. account.partner.com 将通过 xxxxx-pkce cookie 生成并返回， code_verifier 并使用 redirect_uri 参数将浏览器重定向到 https://account.redacted.com/authorize

1
2
3

HTTP/2 302 Found
Set-Cookie: xxxxx-pkce=<code_verifier>; Path=/; Expires=Tue, 26 Mar 2024 11:25:07 GMT
Location: https://account.redacted.com/authorize?redirect_uri=https%3A%2F%2Faccount.partner.com%2Foauth_callback%3Fnext%3D%2Fabc&response_type=code&code_challenge=<code_challenge>

• Particularly, this redirect_uri is
  特别是，这是 redirect_uri

1

https://account.partner.com/oauth_callback?next=/abc

• If you wonder what is code_verifier, according to auth0.com
  如果你想知道什么是 code_verifier ，根据 auth0.com

The PKCE-enhanced Authorization Code Flow introduces a secret created by the calling application that can be verified by the authorization server; this secret is called the Code Verifier. Additionally, the calling app creates a transform value of the Code Verifier called the Code Challenge and sends this value over HTTPS to retrieve an Authorization Code. This way, a malicious attacker can only intercept the Authorization Code, and they cannot exchange it for a token without the Code Verifier.
PKCE 增强的授权代码流引入了由调用应用程序创建的密钥，该密钥可由授权服务器验证;此密钥称为代码验证程序。此外，调用应用会创建名为代码质询的代码验证程序的转换值，并通过 HTTPS 发送此值以检索授权代码。这样，恶意攻击者只能拦截授权代码，并且无法在没有代码验证程序的情况下将其交换为令牌。

• So basically, code_verifier is an additional layer to protect the Authorization Code, in order to exchange for the access token, we also need the code_verifier associated with that authorization_code
  所以基本上， code_verifier 是保护的 Authorization Code 附加层，为了交换访问令牌，我们还需要与之 code_verifier authorization_code 相关的

4,5. User will be prompted a login page at the account.redacted.com SSO Portal, or redirected if already logged in.
4,5. 用户将在 account.redacted.com SSO 门户上被提示登录页面，如果已登录，则会重定向。

6. The redirect_url will be formed by concatenating the authorization_code after the previously supplied redirect_uri
redirect_url authorization_code 将通过连接先前提供的 redirect_uri

   1	redirect_url = redirect_uri + "<authorization_code>"

7. Then, the browser will be redirected to the redirect_url
   然后，浏览器将被重定向到 redirect_url

8. Next account.partner.com will be able to get the authorization code through the redirection from account.redacted.com.
   接下来 account.partner.com 将能够通过重定向从 获取 account.redacted.com 授权代码。

   • The redirection URL will look something like this:
     重定向 URL 将如下所示：

     1	https://account.partner.com/oauth_callback?next=/abc&code=<authorization_code>

     • next: is the URL to be redirected after the authorization_code is used and verified successfully
       next ：是成功使用和验证后要重定向的 authorization_code URL
     • code: is where the application will get the authorization_code
code ：是应用程序将获取 authorization_code

   • The front end Javascript will then use the code to exchange for the access token at POST / access_token
     然后，前端 Javascript 将使用 在 code POST / access_token

     1 2 3 4 5 6 7

     POST /access_token HTTP/2 Host: account.partner.com Cookie: xxxxx-pkce=<code_verifier> Content-Length: 306 Content-Type: application/x-www-form-urlencoded code=<authorization_code>&grantType=authorization_code&redirect_url=<redirect_url>

9. Notice that the code_verifier must be associated with the authorization_code in order for the exchange of access token to be successful.
   请注意，必须与 authorization_code 相关联， code_verifier 才能成功交换访问令牌。

   If the code_verifier and authorization_code are valid, the access token will be returned and set as the cookie.
   如果 code_verifier 和 authorization_code 有效，则将返回访问令牌并将其设置为 cookie。

   1 2	HTTP/2 201 Created Set-Cookie: accessToken=na3+CYtH7TAt+kjebEZgjJ4m37V8Qkxb+GhMw1FlU7gnELDBevy3qGJADAsNfBKSjoujZhgILLU+M8n49DrRd8+yZS1Jco2M04KWqbp64B8ASHPM6llTqZc=; Domain=partner.com

10. Finally, the application will redirect the page to the URL at the next parameter of the oauth_callback endpoint from step 3, which is redirecting to https://account.partner.com/abc
    最后，应用程序会将页面重定向到步骤 3 中 oauth_callback 终结点 next 参数处的 URL，该参数重定向到 https://account.partner.com/abc

2. Trying out the text-book OAuth attack 📚
2. 尝试教科书上的OAuth攻击 📚

Our first approach ís to tamper the redirect_uri parameter at step 3 of the login flow. For example:
我们的第一种方法是在登录流程的第 3 步篡改 redirect_uri 参数。例如：

1

https://account.redacted.com/authorize?redirect_uri=https://attacker.com&response_type=code

We will then send this tampered link to the victim.
然后，我们会将这个被篡改的链接发送给受害者。

If the login flow is successful, the code will be attached to the https://attacker.com domain at step 7, thus the attacker can obtain the authorization code.
如果登录流程成功，则代码将在步骤 7 附加到 https://attacker.com 域，因此攻击者可以获取授权代码。

1

https://attacker.com/?code=<authorization_code>

However, things aren’t that easy ¯\(ツ)/¯
然而，事情并没有那么容易 ̄\（ツ）/ ̄

The application would reject any redirect_uri which isn’t having the domain name account.partner.com and only accepts http and https protocol.
应用程序将拒绝任何 redirect_uri 没有域名 account.partner.com，只接受 http 和 https 协议。

Fortunately, we can still modify the URL path to anything we want. For example:
幸运的是，我们仍然可以将 URL 路径修改为所需的任何内容。例如：

1

https://account.redacted.com/authorize?redirect_uri=https://account.partner.com/<anything_here>&response_type=code

Another way to exploit this is to find an Open Redirect on https://account.partner.com so we can redirect the authorization code to our server.
利用此漏洞的另一种方法是找到一个打开重定向， https://account.partner.com 以便我们可以将授权代码重定向到我们的服务器。

In step 10 of the login flow, we have mentioned that there is another redirect at https://account.partner.com/oauth_callback?next=
在登录流程的第 10 步中，我们提到还有 https://account.partner.com/oauth_callback?next= 另一个重定向

One interesting thing is there isn’t any 302 or redirecting status code from the server, indicating that the application is being redirected using JavaScript.
有趣的是，服务器没有任何 302 或重定向状态代码，表明应用程序正在使用 JavaScript 重定向。

Let’s examine the redirect sink!
让我们检查一下重定向接收器！

Click here to read part 2 and see how we escalated the DOM XSS to a 1-click Account Takeover.
单击此处阅读第 2 部分，了解我们如何将 DOM XSS 升级为一键式帐户接管。

原文始发于thefrogsec：How we escalated a DOM XSS to a sophisticated 1-click Account Takeover for $8000 – Part 1