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:

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

II. Understanding the OAuth login flow and the text-book OAuth attack

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 and their partner sites as because we didn’t have the permission to disclose the program’s name.
我们将目标 称为及其合作伙伴网站, 因为我们无权披露该计划的名称。

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.
在所有功能中,我们选择首先测试登录流程,因为这可能是高/严重漏洞隐藏在众目睽睽之下的地方。 will have a Single Sign On (SSO) portal where other partner sites will integrate this portal to log the users in their services. 将具有单点登录 (SSO) 门户,其他合作伙伴站点将在其中集成此门户以将用户登录其服务。

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

How we escalated a DOM XSS to a sophisticated 1-click Account Takeover for 00 - Part 1
  1. The user will click login to

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

HTTP/2 302 Found
Set-Cookie: xxxxx-pkce=<code_verifier>; Path=/; Expires=Tue, 26 Mar 2024 11:25:07 GMT
  • Particularly, this redirect_uri is
    特别是,这是 redirect_uri

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

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 SSO Portal, or redirected if already logged in.
4,5. 用户将在 SSO 门户上被提示登录页面,如果已登录,则会重定向。

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

    redirect_url = redirect_uri + "<authorization_code>"
  2. Then, the browser will be redirected to the redirect_url
    然后,浏览器将被重定向到 redirect_url

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

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

      • 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

      POST /access_token HTTP/2
      Cookie: xxxxx-pkce=<code_verifier>
      Content-Length: 306
      Content-Type: application/x-www-form-urlencoded
  4. 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_verifierauthorization_code 有效,则将返回访问令牌并将其设置为 cookie。

    HTTP/2 201 Created
    Set-Cookie: accessToken=na3+CYtH7TAt+kjebEZgjJ4m37V8Qkxb+GhMw1FlU7gnELDBevy3qGJADAsNfBKSjoujZhgILLU+M8n49DrRd8+yZS1Jco2M04KWqbp64B8ASHPM6llTqZc=;
  5. 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
    最后,应用程序会将页面重定向到步骤 3 中 oauth_callback 终结点 next 参数处的 URL,该参数重定向到

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

How we escalated a DOM XSS to a sophisticated 1-click Account Takeover for 00 - Part 1

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


We will then send this tampered link to the victim.

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


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

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

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


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

In step 10 of the login flow, we have mentioned that there is another redirect at
在登录流程的第 10 步中,我们提到还有 另一个重定向

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

版权声明:admin 发表于 2024年4月11日 下午4:48。
转载请注明:How we escalated a DOM XSS to a sophisticated 1-click Account Takeover for $8000 – Part 1 | CTF导航