XSS + OAuth Misconfigs = Token Theft and ATO

Hi 你好all, In this blog post, I will walk through finding an ATO via OAuth misconfigurations and stealing Auth Tokens through collaborative work with my friends Ynoof and Refaat
在这篇博文中，我将介绍如何通过 OAuth 错误配置查找 ATO，并通过与我的朋友 Ynoof 和 Refaat 的协作来窃取身份验证令牌

The story begins with finding XSS at sub1.target.com The problem was that the program was paying lower bounties for this subdomain, so our target was to escalate this XSS to ATO on the main target app app.target.comsince the program was paying much more for this subdomain.
故事从在 sub1.target.com 找到 XSS 开始问题在于该程序为该子域支付的赏金较低，因此我们的目标是将此 XSS 升级到主要目标应用程序上的 ATO，app.target.com因为该程序为此子域支付的费用要高得多。

Looking at the auth mechanism of sub1.target.com, we found that it was authenticated via a cookie-based JWT token, while the auth mechanism in app.target.com was via an Authorization header-based JWT. The JWT value on the two subdomains was different, but surprisingly, the JWT from sub1.target.com worked for authentication on app.target.com!
查看 sub1.target.com 的身份验证机制，我们发现它是通过基于 cookie 的 JWT 令牌进行身份验证的，而 app.target.com 中的身份验证机制是通过 Authorization header-based JWT .两个子域上的 JWT 值不同，但令人惊讶的是，sub1.target.com 的 JWT 可用于 app.target.com 上的身份验证！

So, if we could leak the JWT auth token from sub1.target.com, we could use it for authentication on app.target.com.
因此，如果我们可以从 sub1.target.com 泄露 JWT 身份验证令牌，我们可以将其用于 app.target.com 上的身份验证。

Unfortunately, the cookie-based JWT token on sub1.target.com was protected with an HttpOnly flag, so it wasn’t possible to access it via the XSS. However, during our analysis of the target’s oauth flow, we found another way to leak these JWT tokens!
遗憾的是，sub1.target.com 上基于 Cookie 的 JWT 令牌受到 HttpOnly 标志的保护，因此无法通过 XSS 访问它。但是，在分析目标的 oauth 流期间，我们发现了另一种泄漏这些 JWT 令牌的方法！

We found this request, which had the JWT token in the response from another subdomain, auth.target.com.
我们发现了这个请求，它在来自另一个子域 auth.target.com 的响应中包含 JWT 令牌。

After further analysis, we found interesting behavior on the previous request. We found that if we changed the response_mode parameter value from post to get, the response will be different. Additionally, we could set any value for the state and nonce parameters and the server would still return the auth token.
经过进一步分析，我们发现了上一个请求的有趣行为。我们发现，如果我们将 response_mode 参数值从 post 改为 get，响应会有所不同。此外，我们可以为 state 和 nonce 参数设置任何值，服务器仍将返回 auth 令牌。

Now with the XSS in sub1.target.com, we can create an iframe that loads the OAuth endpoint on auth.target.com. Fortunately there weren’t any X-Frame-Options or CSP in place to prevent framing of this endpoint, However, the SOP will prevent access to the contentWindow object of an iframe from a different origin.
现在，有了 XSS sub1.target.com，我们可以创建一个 iframe，用于在 auth.target.com 上加载 OAuth 端点。幸运的是，没有任何 X-Frame-Options 或 CSP 来阻止此端点的框架，但是，SOP 将阻止从其他来源访问 iframe 的 contentWindow 对象。

We considered if both subdomains set document.domain = 'target.com', putting them into the “same origin” state.
我们考虑了两个子域是否都设置 document.domain = 'target.com' 了 ，将它们置于 “同源” 状态。

This technique was used to relax SOP between subdomains under the same second-level domain. If both subdomains explicitly set the document.domain property to the parent domain domain.com, they will share the same origin, allowing cross-origin access.
该技术用于放宽同一二级域下子域之间的 SOP。如果两个子域都显式地将 document.domain 属性设置为父域 domain.com，则它们将共享相同的源，从而允许跨域访问。

However, this technique is no longer supported by modern browsers like chrome
但是，chrome 等现代浏览器不再支持此技术

Instead, we found that when we navigated to https://auth.target.com/oauth?client_id=redacted&redirect_uri=https://auth.target.com/endpoint.jsp&response_mode=get&response_type=code&scope=redacted&state=redacted&nonce=redacted, it redirected us to https://sub1.target.com#token=. As a result, the page is now considered to have the same origin, allowing us to access the location.href property of the window and extract the token from the URL fragment.
相反，我们发现当我们导航到 https://auth.target.com/oauth?client_id=redacted&redirect_uri=https://auth.target.com/endpoint.jsp&response_mode=get&response_type=code&scope=redacted&state=redacted&nonce=redacted 时，它会将我们重定向到 https://sub1.target.com#token= 。因此，该页面现在被认为具有相同的来源，允许我们访问窗口的 location.href 属性并从 URL 片段中提取令牌。

var auth = document.createElement('iframe');
xe.setAttribute('src',' https://auth.target.com/oauth?client_id=redacted&redirect_uri=https://auth.target.com/endpoint.jsp&response_mode=get&response_type=code&scope=redacted&state=redacted&nonce=redacted');
auth.setAttribute('id','lol')
token = new URLSearchParams(document.getElementById("lol").contentWindow.location.hash.split('#')[1]).get('token');

After initiating the request to get the token fragment from the URL, we can send it to the attacker’s server.
发起从 URL 获取 Token 片段的请求后，我们可以将其发送到攻击者的服务器。

Since the JWT auth token was stolen from the authentication flow at auth.target.com using XSS on sub1.target.com, we can then include the stolen JWT auth token in requests to change victims’ email addresses on app.target.comto achieve ATO.
由于 JWT 身份验证令牌是在 auth.target.com 上使用 XSS on sub1.target.com 从身份验证流程中窃取的，因此我们可以将被盗的 JWT 身份验证令牌包含在请求中，以更改受害者在 app.target.com上的电子邮件地址以实现 ATO。

The full attack flow can be shown as following:
完整的攻击流如下所示：