简介

跨站脚本（又称 XSS）已经理所当然地占据了最受欢迎的网络漏洞之一的位置。自从它第一次出现在互联网的黑暗时代以来，无数漏洞在各个网站上被发现。因此，毫不奇怪，自 2004 年 OWASP TOP-10 列表首次发布以来，XSS 一直被一直被强调为最高风险之一！

毫无疑问，这样一个备受关注的漏洞肯定已经被所有人——供应商、开发人员、从业者、安全社区——重视和优先处理了，事实上确实如此。

多年来，已经部署了许多保护层来检测 XSS 并防止其被利用。从攻击者的角度来看，这些保护措施构成了真正的挑战。尽管 XSS 仍然存在并且仍然有效，但要成功利用它变得比以前困难得多，这解释了为什么我们逐渐在野外看到更少的实例。

然而，与网络安全生态系统中许多其他案例类似，有时新的、看似无关的发展可能导致旧的、有时被遗忘的漏洞再次出现。在这篇博客文章中，我们展示了为什么这正是当 XSS 与新兴技术 OAuth 巧妙结合时的情况。

XSS ♥️ OAuth

展示新的攻击技术的更好方式是通过真实世界的例子吗？这篇博客文章将做到这一点。虽然 Salt Labs 已经发现了许多我们成功利用这个问题的实例，但我们决定提醒您两个非常高调的案例，如果这些问题没有得到解决，影响可能会非常严重。这篇文章是两部分系列中的第一部分，每家公司将在单独的文章中揭示。

我们在这里发布的每一项发现都遵循了我们严格的协调披露政策，以确保这些特定案例已经得到解决，进一步的利用是不可能的。通常，我们通常寻找具有漏洞赏金或类似计划的研究目标，因为这表明他们优先考虑安全，并邀请研究人员发现漏洞。

XSS 历史

首先，我们将提供一些关于 XSS 的非常基础的背景知识，以及多年来为其开发的保护措施。如果这是您感到熟悉的领域，请随时跳转到缓解措施部分。

基本

XSS，简而言之，是在受害者的浏览器上运行 JavaScript（从现在开始 - JS）代码的能力。

让我们以一个易受攻击的网站为例，https://xss.example.com，该网站将您的输入输出到屏幕上。

例如，URL： ‍ https://xss.example.com/?input=Hello‍

将“Hello”输出到屏幕。

如果您编写 HTML/JS 代码而不是输入，浏览器会认为该代码是由后端生成的，并将其解析为合法的 HTML/JS。

例如，URL：

https://xss.example.com/?input=

将输出“”，这将导致浏览器弹出一个带有文本“xss”的消息。

当受害者在 https://xss.example.com 中存储了秘密凭据，比如 cookies 时，情况就变得有趣起来。 ‍ 在典型的 XSS 攻击中，攻击者可以使用以下 URL 来窃取这些 cookie：

https://xss.example.com/?input=. ‍ 攻击者可以通过电子邮件、社交媒体或其他方法向其他人（受害者）发送上述链接。当受害者点击此链接时，他们的 cookie，包括存储在 https://xss.example.com 中的凭据，将传递给攻击者。这是完全的账户接管。 ‍

而且，嗯...就是这样了（或者至少这就是你需要的全部背景）。

缓解措施

正如我们所提到的，多年来已经设计了许多 XSS 保护措施。如果您负责网站安全，并希望防范 XSS 攻击，有几种关键策略可以实施：

1. 手动输入消毒和输出编码 这是最古老但最常见的缓解措施。开发人员需要对用户输入进行清理，并确保来自输入的 HTML/JS 代码不会被解析为输出中的 JS/HTML。这种方法给开发人员带来了很大的责任，并且在很多情况下，完全清理输入并不是一件简单的事情，错误往往会发生。

2. 使用现代 Web 框架 如果网站是使用 React、Angular 或其他类似的现代 JavaScript 框架开发的，那么它会通过自动转义 JSX 中嵌入的任何值来提供强大的内置 XSS 保护。这种自动转义有效地阻止它们被执行为 HTML 或 JavaScript。

3. 仅限 HTTP 除了输入过滤之外，网站应采取的另一种常见方法是 HTTP-Only 功能，通过阻止客户端脚本访问 cookie 值，显著增强了安全性。该属性确保 cookie 仅通过 HTTP 请求发送到服务器，使其对在浏览器中运行的 JavaScript 不可访问。

在xss.example.com的示例中，如果 HTTP-only 被呈现，那么以下链接：

https://xss.example.com/?input=

将在受害者上运行一个 JavaScript 代码，但“document.cookie” 方法不会返回敏感的 cookie，使得攻击者无法利用。

4. CSP 内容安全策略（CSP）是另一种常见方法，允许网站管理员指定内容（如脚本和图像）的安全来源，有效地阻止从未经授权的来源注入的恶意脚本。

尽管我们上面提到的缓解措施是必不可少的，我们鼓励每个开发者使用它们，但它们并非绝对安全，攻击者仍然有办法绕过它们。

XSS ♥️ OAuth ♥️ Hotjar

我们将以 Hotjar 为例。这是一家知名公司，为超过一百万个网站提供服务，包括全球知名品牌，如 Adobe、Microsoft、Panasonic、Columbia、RyanAir、Decathlon、T-Mobile、Nintendo 等。Hotjar 是产品团队的领先解决方案，他们希望超越传统的网络和产品分析，以便能够共情和理解他们的用户，连接发生的事情和为什么发生的原因，从而改善用户体验（UX）并创造客户喜悦。

由于 Hotjar 解决方案的性质，如记录用户屏幕和键盘活动，它收集的数据可能包括大量的个人和敏感数据，如姓名、电子邮件、地址、私人消息、银行详细信息，甚至在某些情况下还包括凭证。无论您是否听说过 Hotjar，很可能您已经与使用其技术的数百万个网站之一进行过互动，这意味着它可能以某种方式收集了您的数据。

通常，在开始研究之前，我们会运行内部自动化检查，以识别网站的“弱”点，只是为了从攻击者的角度了解可能有趣的内容。 从今天开始，我们决定将我们的其中一个工具公开，所以如果您是网站所有者，您可以在这里访问我们的工具。

Hotjar 是一个现代网站的绝佳示例，遵循有关 XSS 的所有最佳实践。因此，在后端搜索传统的 XSS 并不是一件简单的事情，我们在这里的方法会有所不同。

我们从https://insights.hotjar.com（主仪表板）下载了所有 JS 源文件。这可以通过这样的工具轻松完成。

分析 JS 代码中漏洞最常见的方法是搜索“Sink 函数”，这些函数是将参数作为 HTML/JS 代码运行的 JS 方法。例如，“document.InnerHTML”、“document.write” 和 “document.location” 等方法。

您可以在 DOM-Based XSS 这里找到更多信息。

在 Hotjar 的情况下，我们尝试了搜索“来源”的反向策略 - JS 代码中从用户获取输入的位置，特别是查询参数。例如，请查看以下代码：

假设 URL 采用https://example.com?name=value的形式，此 JS 代码从 URL 中读取“value”。

有多种方法可以在代码中搜索模式，但为了简单起见，我们从基本的查找命令开始。 以下查找命令在 Hotjar 中的所有 JS 文件中搜索 URLSearchParams(window.location.search)，并为每个匹配打印 50 行代码：

我们找到了 24 个匹配项，总共有 24*50 = 1,200 行需要阅读。

阅读和检查了几场比赛后，以下比赛引起了我们的注意：

除了URLSearchParams(window.location.search),您还可以注意下面的函数window.location.replace(e)。此时，很难知道这行代码的确切流程以及参数是从哪里来的。

虽然可以仔细阅读代码，但运行代码会更加有效。因此，我们在 Hotjar 网站上使用 Chrome 调试工具，搜索了那行特定的代码，并在那里设置了断点。

在阅读代码并在 Chrome 中运行后，这就是代码的作用：

如果：

“next”参数已提供且不以“/”开头， “fromLMS”被呈现在“next”查询参数内 returnURL 也出现在“next”查询参数中 然后：JavaScript 代码使用 window.location.replace 将用户重定向到 returnURL。 使用 window.location.replace，您还可以通过使用“URL” javascript:来运行 javascript，从而可以通过以下链接触发 XSS：

https://insights.hotjar.com/?next=?fromLMS=1%26returnURL=javascript:alert('Hello XSS')&extraVar=jsvar32312

请注意，“extraVar”角色仅用于 WAF 保护绕过，并与手头的问题没有直接关联。

绕过 HTTP-Only: 攻击者常用的利用技术是利用 XSS 读取浏览器的 cookie。然而，在这种情况下，cookie（至少是重要的那些）被设置为 HTTP-only 标志。因此，结果是我们无法用 JavaScript 代码读取这些 cookie，所有经典的 XSS 利用都不会在这里起作用。

OAuth 来拯救 Hotjar 中的一个功能，以及今天几乎所有其他现代网站的一个功能，是基于 OAuth（授权的开放标准）的社交登录。

当您使用 Google 连接到 Hotjar 时，Hotjar 会将您发送到 Google，Google 会为您生成一个秘密令牌，然后您将该秘密传递回 Hotjar 以完成身份验证。

例如，如果您点击“使用 Google 登录”，Hotjar 将会将您重定向到 Google

https://accounts.google.com/o/oauth2/v2/auth?response_type=code&client_id=145303889798-f167kpmuqrlh4rd597teoj633et6ku9i.apps.googleusercontent.com&redirect_uri=https://insights.hotjar.com/api/sso/google-auth&scope=openid+email+profile&state=[state]

谷歌将自动（假设用户以前已经在谷歌中批准了 Hotjar）将您重定向回 Hotjar，使用包含秘密代码的以下 URL：

https://insights.hotjar.com/api/sso/google-auth?state=[state]&code=[secret_code]

换句话说 - 在 OAuth 流程结束时，秘密代码将位于 URL 中 - 这是 JavaScript 代码可以读取的内容。

*如果您想了解有关 OAuth 如何工作的更多信息，您可以在这里找到我们的逐步解释。

将 XSS 与这个新的社交登录（OAuth）功能结合起来，实现工作利用，我们使用一个 JavaScript 代码，在新窗口中启动一个新的 OAuth 登录流程，然后从该窗口读取令牌：

使用这种方法，javascript 代码打开一个新标签到 Google，Google 自动将用户重定向回 https://insights.hotjar.com 并在 URL 中包含 OAuth 代码：

https://insights.hotjar.com/api/sso/google-auth#state=...&code=[secret_code]

JS 代码从新标签页读取 URL（这是可能的，因为如果您在一个窗口的域上有 XSS，那么该窗口可以访问同一来源的其他窗口），并从中提取 OAuth 凭据。

请注意，我们将原始的 OAuth 链接更改为 Google - 我们使用响应类型“code,token”而不是仅“code”，这使得 Google 将代码发送到哈希片段（#code=...）。这使我们能够从 URL 中读取代码并确保 Hotjar 不会消耗该代码，该代码只能消耗一次。

一旦攻击者获得受害者的代码，他们可以在 Hotjar 中启动一个新的登录流程，但用受害者的代码替换自己的代码 - 导致完整的账户接管。

总结一下 - 恶意链接看起来是这样的（javascript 代码被插入为 base64 值）：

https://insights.hotjar.com/?next=?fromLMS=1%26returnURL=javascript:eval(atob('CmI9d2luZG93Lm9wZW4oIm…'))&extraVar=jsvar32312

‍当受害者（Hotjar 的账户所有者）点击此链接（其中包含一个合法域），他们的凭据将被传递给攻击者。有几种潜在的攻击向量可以用来获取一个恶意链接到 Hotjar 账户所有者/网站管理员。例如，Hotjar 有一个反馈功能，用户可以写反馈，网站所有者会阅读。

正如我们之前所写的，这个问题已完全解决，Hotjar 在缓解这个问题上做得非常出色。

影响

正如前面提到的，HotJar 存储用户录制，包括键盘和鼠标活动。

这些数据包括姓名、电子邮件、地址、私人消息、银行详细信息、凭证（在特定情况下）等。

在默认设置中，HotJar 会对数据进行审查：正如您所看到的，在账户劫持的情况下，攻击者可以更改设置并使大部分敏感数据可用。尽管在这种情况下，这似乎并不包括所有类型的信息（例如信用卡详细信息），但确实包括大量其他敏感和有价值的信息。请注意，这些用户包括网站的管理员，这意味着攻击者可以了解有关网站本身的其他数据（例如控制面板的位置），甚至可以利用这些数据接管网站，具体取决于收集了哪些数据。 ‍

接下来是什么？

在接下来的部分，我们将探索另一家知名公司，在那里我们发现了一种新的（与当前这家公司有点不同）将 XSS 和 OAuth 结合的方法。敬请关注。

要了解更多关于 Salt 如何帮助保护您的组织免受这些风险或其他 API 风险的信息，您可以联系代表或安排个性化演示。如果您对其与您的资产的相关性感到不确定，您可以使用Salt-Labs 的扫描免费检查您的域名是否存在风险和漏洞。

披露时间表

我们在此协调披露过程中遵循了以下时间表。再次感谢 Hotjar 采取行动解决这些严重漏洞。

• Salt Labs 发现 Hotjar 中的漏洞：2024 年 4 月 17 日
• Hotjar 安全团队部署缓解措施，Salt Labs 确认漏洞不再有效：2024 年 4 月 19 日
• Salt Labs 向 Hotjar 安全团队发送了此技术博客，详细介绍了该漏洞：7 月 19 日
• Salt 营销团队与 Hotjar 营销团队分享博客和新闻稿草稿：7 月 19 日
• Salt 发布博客和新闻稿：7 月 29 日 ‍ ‍