021-54410609
浏览器供应商不断调整和完善浏览器功能以提高安全性。实施同站点 Cookie 是供应商努力缓解跨站点请求伪造 （CSRF） 攻击的一个主要示例。但是，并非所有安全措施都是万无一失的。为了对抗跨站点脚本 （XSS），浏览器供应商引入了一些功能，这些功能虽然是出于好意，但有时却达不到他们的承诺。此外，浏览器的行为有时可以被视为一种安全功能，而实际上，它只是一种特殊的行为。
这文重点介绍了不起眼的锚点标签，特别是它如何与不同的目标属性和协议一起表现。我们将观察其不一致的行为如何使安全团队感到困惑，使错误被忽视并可能成为利用的目标。
许多网站允许用户输入 URL，例如指向社交媒体资料或个人网站的链接。然后，这些链接将显示在网站上，这可以通过跨站点脚本 （XSS） 创建利用机会。此类攻击的常用方法涉及在 URL 中使用 JavaScript 伪协议。成功利用此方法通常取决于 URL 验证不充分的服务器。
我在几个网站上遇到了一个有趣的场景，尽管成功地将 JavaScript 协议 URL 放入锚标记中，但浏览器还是阻止了它的执行。当锚点代码将目标属性设置为“_blank”时，就会发生这种情况。在这些情况下，单击链接会打开一个新选项卡，显示“about：blank#blocked”，而不是执行 JavaScript 有效负载。我决定更深入地研究这个问题，看看是否有解决方法。
谁说安全没有捷径？
好吧，可以使用键盘快捷键来利用这一点。Chrome 和 Firefox 之间存在一些差异。尽管如此，即使锚点标记的目标属性设置为“_blank”，在单击链接时按住 CTRL 仍会成功执行 JavaScript 有效负载。其他快捷方式，如单击鼠标中键或 CTRL+ENTER，也可以使用。
后来我才知道，DCLabs 的博客文章“XSS 和鼠标中键的奇特案例”中已经记录了这种技术。话虽如此，除了希望用户不小心使用其中一种快捷方式外，他们没有提供任何实用的方法来利用它。
可以采用更系统的利用方法，特别是通过iFrames与点击劫持攻击相结合。如果易受攻击的页面可以嵌入到另一个网站中，则此方法是可行的。使用不可见的 iframe 并使用 CSS 进行精确定位，可以对齐 iframe，以便在按住 CTRL 按钮的同时单击屏幕上的任意位置可以触发漏洞利用。可以在恶意网站上促进此设置，在恶意网站上，用户可能会被指示按住 CTRL 按钮作为交互式元素的一部分，例如在线游戏或虚假的 CAPTCHA 挑战。
我联系了 Google，将此行为报告为潜在错误，因为我无法确定此行为是否作为安全功能引入。谷歌澄清说，这不是安全防御措施，因此使用带有 JavaScript URL 的锚标记是不安全的。他们一致认为，修复此问题以确保更一致地处理 JavaScript URL 将是有益的。
本文的其余部分将介绍我根据上述技术向Microsoft和Wix报告的两个存储的XSS漏洞。
Microsoft 应用门户
企业使用 myapps.microsoft.com 网站或“我的应用”门户来管理和访问组织应用程序，允许用户发现、请求和组织应用程序，包括为网站创建书签。
这个漏洞很容易被发现，但极难利用。负责创建新书签的 API 端点缺少对用户提供的 URL 的服务器端验证。
服务器允许任何 URL（包括 JavaScript 协议）指向存储的 XSS。但是，正如我之前所解释的，使用 URL 的锚标记具有属性 target=_blank，这使得利用变得更加困难。此外，我找不到任何跨帐户共享这些书签的方法，这意味着存储的 XSS 仅在我们的帐户上，这不是很有用。
反向账户接管
Microsoft My Apps网站允许用户同时登录多个帐户，并根据需要在帐户之间切换。由于我们只能利用我们的帐户，因此让目标接管它将使我们能够访问他们的帐户，因为所有帐户都具有相同的来源。这个想法是找到一种方法来自动将任何 Microsoft 帐户登录到已经存储了 XSS 有效负载的恶意帐户中。
SSO 集成是检验这一假设的完美载体。通常，Microsoft 会将用户重定向到控制身份验证的组织域，这意味着我们可以创建这样的组织并自动登录任何用户。我快速创建了一个概念验证，演示了如何在没有用户交互的情况下在后台选项卡中完成此操作。
漏洞利用
现在，我们有了一种与任何 Microsoft 用户共享存储的 XSS 的方法，我们需要确保也可以将存储的 XSS 嵌入到 iframe 中。幸运的是，myapps.microsoft.com 不使用 x-frame-options 标头，也没有禁止其他源嵌入站点的 CSP 策略。
由于用户登录了我们的帐户，我们确切地知道恶意书签的位置，使我们能够将其完美地定位在 iframe 中。通过一些 CSS，我们可以缩放 iframe 并使其不可见，因此在我们的恶意网站内的任何点击都会导致用户点击我们的书签。为了防止用户在不使用快捷方式的情况下单击链接，我在 iframe 中添加了“saNDBox”属性，该属性会阻止所有弹出窗口。单击该链接将重点放在锚标记上，这对于 CTRL+ENTER 等快捷方式很有帮助。该快捷方式会在新选项卡中打开当前选定的锚标记的链接，或者在我们的例子中，执行我们的任意 JavaScript。
在我为 Microsoft 制作的概念验证中，我首先让用户单击屏幕上的任意位置（专注于锚标记），然后要求用户按键盘上的 CTRL+ENTER。如果用户按照说明操作，则将执行任意 JavaScript。
重要的是要记住，当 JavaScript 被执行时，目标会登录到我们的帐户中，这并不是很有用。因此，需要做更多的工作来使此漏洞影响其他帐户。
所有已连接帐户的某些访问令牌都存储在 localStorage 中。即使用户在帐户之间切换，这些令牌也会保留。这些访问令牌的范围包括：
- OpenID
- profile
- application.readwrite.all
- directory.read.all
- https://graph.microsoft.com/user.read
- https://graph.microsoft.com/.default
- https://webshell.suite.office.com/shellinfo.read
- https://webshell.suite.office.com/.default
我使用泄露的访问令牌通过 Microsoft Graph API 访问用户公司的 Active Directory 记录、网站、个人数据等。
Wix市场
Wix 是世界上最受欢迎的网站建设平台之一，它有一个市场，允许开发人员创建用于 Wix 网站的组件。
在探索 Wix 开发人员平台时，我发现某些 URL 输入字段，例如“演示站点 URL”或“条款和条件 URL”，缺乏适当的服务器端验证，允许使用 JavaScript 协议。
我还发现 Wix 允许开发人员在发布之前预览他们的应用列表，使用以下请求生成的 JSON Web 令牌 （JWT）：
将打开一个新窗口，显示以下 URL，该 URL 显示我们的链接。
https://www.wix.com/market?appMarketParams={JWT Token}
如果 JWT 有效，则生成的 URL 可以与任何人共享。
同样，具有 XSS 有效负载的 URL 的锚点标记将目标属性设置为“_blank”。与Microsoft类似，Wix 允许嵌入易受攻击的页面。我快速创建了一个概念验证：我在 iframe 中加载页面并定位链接，以便当用户按住 CTRL 并单击它时，我们的 JavaScript 代码将在 www.wix.com 上下文中执行。
结束语
我怀疑这些相对容易检测的错误没有尽快得到解决的原因是由于浏览器行为令人困惑。我记得几年前在一个知名网站上遇到过这种错误，但从未报告过，因为我认为它不会被利用。浏览器打开了一个新选项卡“about：blank#blocked”，让我认为攻击被“检测到”，所以我只是继续前进。
我认为改变这种浏览器行为很重要。它可能会使安全团队、漏洞赏金猎人和安全研究人员感到困惑，在我看来，这会导致未报告的错误净增加和安全风险的增加。
我要感谢 Microsoft 和 Wix 解决我们的发现。帮助使这些平台更加安全是有益的。
揽阁信息可提供的部分安全产品和解决方案信息
联系揽阁信息，您可以获取到更多满足全球合规性要求的信息安全产品资料，以及相关的整体解决方案的相关资料。如：
-
数据库访问控制：揽阁LGPAC系统
-
通用HSM：Luna HSM、ProtectServer HSM
-
支付HSM：payShield 10K
您还可以得到揽阁信息所提供的优质服务。
揽阁信息 · 值得您信赖的信息安全顾问！
联系我们
免费试用留言
客服电话