文章总结： 本文揭示了单页应用程序中硬编码敏感凭据的安全风险，作者通过两个实际案例展示了AzureAD客户端密钥和APIM订阅密钥暴露在客户端JavaScript中导致账户完全接管的攻击链。关键发现包括左移工具无法检测构建时注入的密钥、CryptoJS加密的虚假安全性以及过度权限配置的放大效应。文章建议加强右移安全检测并审查权限分配原则。 综合评分： 85 文章分类： 漏洞分析,渗透测试,安全开发,安全建设,红队

---

账户劫持链-流传至今的秘密

haidragon haidragon

安全狗的自我修养

2026年5月20日 12:01 中国台湾

在小说阅读器读本章

去阅读

官网：http://securitytech.cc

运行时安全漏洞尚未得到弥补

按回车键或点击查看完整尺寸的图片

多年来左移技术的投资，以及一个硬编码的关键节点仍然保留在生产环境中。

作者：赫曼特·戈里贾拉

改变我对秘密看法的一项发现

在进行安全评估时，我发现凭据位于客户端 JavaScript 包中，每个打开 DevTools 的访问者都可以看到这些凭据。

我拥有真实的 Azure 凭证，于是我开始思考：可以用它们做什么？

这个问题引发了一场完整的账户劫持链，而劫持的源头仅仅是应用程序提供给所有访问者的一个 JavaScript 文件中的四个值。受影响的组织在其代码库中启用了针对拉取请求的静态密钥扫描和代码库扫描。然而，这些扫描都没有发现这些凭据，因为它们只扫描开发者提交的内容，而不扫描应用程序提供的内容。

同样的模式在同一项目的后续第二个应用程序中再次出现，该应用程序采用了不同的代码库和不同的团队，但最终结果却相同。

负责任的披露

本文所述的两项发现均在经授权的安全评估过程中被发现并进行了深入调查。相关发现已立即报告给受影响的组织，并已进行补救，且在发布本文之前已通过重新测试验证。除确认漏洞可利用性所必需的数据外，未访问任何用户数据。

本文中的屏幕截图来自InsecureShield，这是一个专为安全演示而构建的受控演示应用程序。所有显示的凭据均为合成凭据，并且已针对其真实提供商进行身份验证测试，确认无法使用。所示模式均来自真实案例，但所示数据并非真实数据。

从查找到完全访问 Azure AD + APIM

Azure API 管理 (APIM) 是一项网关服务，它位于后端 API 的前端，并通过两种不同的凭据类型强制执行访问：Azure AD 持有者令牌（由身份提供程序颁发的 JWT）和 APIM 订阅密钥（特定于网关的、作用域限定于 API 产品的通行密钥）。访问受保护的终结点需要这两种凭据。典型的 Azure 原生单页应用程序通过 Azure AD 对用户进行身份验证，接收令牌，然后通过 APIM 网关调用后端 API，并在每个请求中同时发送持有者令牌和订阅密钥。

按回车键或点击查看完整尺寸的图片

Azure AD + APIM 请求流

Azure AD + APIM 请求流程。双凭证网关：每次请求都需提供 Bearer 令牌和订阅密钥。

泄露的凭据不仅仅是一个 API 密钥。在生产应用程序的客户端 JavaScript 包中，存在四个值，这些值已通过 Azure AD 身份验证，并受 APIM 保护，服务于真实用户。

按回车键或点击查看完整尺寸的图片

Azure凭据集。其中四个凭据中有两个绝对不能出现在浏览器中。

在 OAuth2 公共客户端流程中，AppID 是合法公开的。AppKey 则不然。它是用于机密客户端流程的客户端密钥，专为服务器到服务器的身份验证而设计，在这种流程中，应用程序代码对最终用户不可见。客户端密钥在架构上对服务器端 Web 应用程序是有效的。问题不在于密钥的存在，而在于它出现在浏览器可访问的 JavaScript 代码中，因此每个打开开发者工具的访问者都能看到它。

按回车键或点击查看完整尺寸的图片

查看源代码：main.js 的秘密

在受控的演示目标上，构建管道生成了 /js/main.js 文件。APIM 订阅密钥、内部服务端点和服务帐户密钥对任何访问者都可见。

这四个值共同构成了应用程序自身身份验证所需的全部信息。调用令牌端点所需的租户 ID 显示在应用程序的登录重定向 URL 中，与其他值一起硬编码在同一个数据包中。租户 ID 是一个公共标识符，由于假定任何访问者都可以获取到它，因此它不计入四个凭据值中。

我调用了 Azure AD 令牌终结点：

POST https://login.microsoftonline.com/{tenant_id}/oauth2/token

grant_type=client_credentials
client_id={AppID}
client_secret={AppKey}
resource={Resource}

它返回了一个经过完全身份验证的 Bearer 访问令牌。（此处显示的是 v1 端点格式。v2 端点使用 /oauth2/v2.0/token，并将 resource 参数替换为 scope 参数。这两个端点在企业级 Azure 环境中均仍在积极使用。）

然后我仔细阅读了 JavaScript 代码包。我不仅是为了寻找隐藏信息，更是为了了解应用程序的构建方式。在压缩后的代码中，隐藏着 API 端点的定义。GET 和 POST 端点及其完整的模式结构清晰地展示了每个端点所需的参数。前端已经为自己的后端编写了文档。

同时使用 Bearer 令牌和 APIM 订阅密钥：

授权：Bearer {token}
Ocp-Apim-Subscription-Key: {SubscriptionKey}

我根据模式重建并调用了端点。用户个人资料数据立即返回。然后我发现了一个账户管理端点，令牌、订阅密钥和重建的模式都相同。我报告了这一发现，没有继续进行后续操作。

一个 APIM 订阅密钥通常对应一个包含多个 API 的产品。

SubscriptionKey   ->   APIM产品“内部 API”
                        |-- /users/ *
                       |-- /payments/ *
                       |-- /admin/ *
`-- /reports/*

一个公开的订阅密钥即可访问该产品中的所有 API。访问权限的范围取决于 APIM 产品的配置方式，此细节在客户端不可见，必须在 APIM 门户中进行评估。

仅暴露的凭证本身就是一项重大发现，无论其最终会揭示什么。公共 JavaScript 文件中的客户端密钥意味着任何访问者都可以冒充该应用程序进行身份验证。其影响范围完全取决于该应用程序被授予的权限。

在这种情况下，放大效应的因素是权限范围条件。Azure AD 授权有两种类型：应用程序权限（令牌充当应用程序本身，是一个独立的身份，不涉及已登录用户）和委派权限（令牌代表特定的已登录用户执行操作，权限范围限定在该用户可执行的操作范围内）。本例中，应用程序被授予了应用程序权限，而委派权限本应更合适且足够。应用程序的客户端身份被赋予了对系统中所有帐户执行用户级操作的权限。如果没有这种配置错误，Bearer 令牌的权限范围将受到限制。而现在，该令牌实际上成为了系统中每个用户帐户的管理员密钥。

完全接管账户。只需修改应用程序所有访问者都能看到的 JavaScript 文件中的四个值即可。

这并非一次复杂的攻击，无需任何漏洞利用框架。攻击链的建立源于读取应用程序已向所有人提供的 JavaScript 文件，并了解其中的凭据解锁了哪些内容。

CryptoJS 上锁的盒子，钥匙用胶带粘在上面。

来自同一项目的不同应用程序，不同的代码库，但最终都使用相同的 Azure AD 凭据模式。

前端 JavaScript 包含一个使用 CryptoJS 加密的配置数据块，这是单页应用程序中的常见模式，即将配置打包到前端并使用客户端加密库进行混淆。这样做的目的是为了保护配置数据，因为它经过了加密。

客户端加密永远无法保护客户端不获取密钥。如果浏览器需要解密配置，解密密钥必须存在于浏览器中。任何打开开发者工具的人都拥有相同的访问权限。

解密密钥硬编码在同一个 JavaScript 文件中，距离加密数据块仅三行之隔。

按回车键或点击查看完整尺寸的图片

查看源代码：main.js（CryptoJS blob 和密钥）

密文、密钥以及连接它们的调用语句，都在同一个文件中，彼此相隔几行。打开浏览器控制台，粘贴这三部分内容，不到一分钟，配置对象就会以明文形式显示出来。

解密本身是一行代码，在浏览器的开发者控制台中使用应用程序自带的同一个 CryptoJS 库运行即可。

CryptoJS.AES.decrypt ( encryptedConfig , hardcodedKey) .toString (CryptoJS.enc.Utf8 )

最终返回的是一个完整的配置对象。其中包含了该应用程序服务主体的 Azure AD 客户端凭据（AppID、AppKey、资源）、APIM 订阅密钥、应用程序通信的内部服务终结点、第三方服务密钥，以及构建管道封装的连接字符串。应用程序运行时所需的一切都以明文形式返回给任何打开开发者工具的人。加密根本起不到任何保护作用。解锁一切的秘密就藏在锁旁边。

解密后的对象包含相同的模式：AppID、AppKey、资源和 Azure AD 客户端凭据，这些凭据嵌入在开发人员认为安全的配置中。与第一个发现的情况一样，服务主体被授予了过于宽松的权限范围，允许应用程序级别的令牌执行用户级别的数据访问操作。

我使用解密后的凭据调用了同一个 Azure AD 令牌终结点，返回了一个 Bearer 令牌。我读取了终结点定义包，发现模式与之前相同，架构嵌入在压缩代码中。经过身份验证的 GET 调用返回了应用程序中任何用户的完整用户配置文件数据，例如姓名、电子邮件地址和帐户详细信息。我报告了此发现并停止了操作。

CryptoJS 加密配置模式尤其危险，因为它会给人一种虚假的安全感。开发者会误以为配置受到了保护而采用这种模式。安全团队看到加密后便会置之不理。解密密钥与密文并列，使得整个配置结构毫无意义，但这只有在读取整个文件而非扫描明文密钥时才会发生。

模式重复出现

在遇到第二个问题链后，我开始思考同一项目中还有多少其他应用程序存在同样的问题。答案并不乐观。

相同的结构在多个互不相关的代码库中反复出现：在构建时注入 Azure AD 客户端凭据，使用 CryptoJS 加密配置（解密密钥位于密文末尾三行），以及直接在客户端 JavaScript 中存储明文凭据。不同的团队，同一组织内的不同技术栈，最终都殊途同归。

这些凭据可以从成功的页面响应以及少量错误响应中恢复，包括受地理位置限制和需要身份验证的页面。单页应用程序包会加载其完整配置，而与会话状态无关。即使应用程序拒绝验证您的身份，JavaScript shell 仍然会加载，并且凭据已预先嵌入其中。

这些应用程序均由运行自动化密钥扫描的组织部署，这些扫描在持续集成/持续交付 (CI/CD) 流程中执行，并在每个拉取请求上启用安全应用安全测试 (SAST)。这些凭据仍然在生产环境中有效。

这并非两个孤立的错误。它们反映了单页应用程序在企业级生产环境中普遍存在的现象。

左移永远看不到的路径

在第二个链之后，我一直在思考的问题是，这些凭证最初是如何到达那里的。

在每起案例中，这都不是疏忽。这些都是成熟且构建完善的应用程序，具备身份验证层、网关控制和结构化的 API 设计。采用这种构建方式的组织通常都使用左移工具。即便如此，密钥还是泄露了。

左移工具已经完成了它们的使命。这些密钥找到了它们未监控的路径，通过构建过程、环境注入、第三方依赖更新或扫描路径之外的部署步骤引入。一个常见的例子是使用 webpack 的 DefinePlugin 在构建时打包的 REACT_APP_* 环境变量，这些实时密钥被嵌入到 JavaScript 包中，从未触及代码仓库，因此对所有 pre-commit 扫描器都不可见。另一个例子是 CI/CD 流水线变量替换。代码仓库中存在一个类似 #{APIM_SUB_KEY}# 的占位符，而实际值则由部署流水线在构建时注入。密钥永远不会存在于 Git 中。它只会在所有扫描器运行完毕后才出现在构建产物中。

源代码（.ts、配置文件）。←左移扫描此处

                          ↓ [管道变量替换/构建]

dist / main.abc123.js（已压缩）← Secret存在于此处-从未被扫描

                          ↓ [部署到 CDN]

线上应用位于https://app.example.com ← Secret 存在于此处 - DAST 忽略它

                          ↓ [浏览器获取 config.json]

运行时获取的配置← Secret在此处获取-对所有内容都不可见

左移工具会扫描你提交的内容，但不会扫描你提供的内容。

按回车键或点击查看完整尺寸的图片

查看源代码：env.js 运行时配置

第二种途径加剧了结构性问题。许多单页应用程序 (SPA) 架构需要在浏览器中配置某些凭据才能正常运行：例如，用于渲染地图的 Google Maps API 密钥、用于用户身份验证的 Firebase 配置、用于初始化支付 SDK 的 Stripe 发布密钥。移除这些密钥会导致应用程序崩溃。当左移扫描器在源文件或 CI/CD 配置中遇到这些密钥时，构建会失败，并且拉取请求会被阻止。遇到这种问题的开发者不会移除密钥，而是通过以下方式之一来阻止扫描器：

• 将文件或目录添加到扫描器的忽略列表或允许列表
• 从扫描范围中排除配置目录或环境文件
• 将警报判定为“假阳性”或“用于测试”
• 向受影响的行添加内联抑制注释
• 将特定密钥模式添加到 SAST 规则集的允许列表中

这种压制是人为的，是在管道压力下进行的。一旦部署完成，相同的凭证就能顺利通过后续所有部署而不被发现，因为扫描器已被明确配置为停止监视它。

右移差距

该行业花费数年时间构建了这幅图景的左侧部分，而右侧部分几乎是空的。

左移，前期制作

• 秘密扫描技术已经成熟、资金充足且广泛部署。GitLeaks、TruffleHog、detect-secrets 和 GitHub Advanced Security 等工具都涵盖了这一层面。
• SAST 已得到 Semgrep、SonarQube 和 Checkmarx 的充分覆盖。
• Snyk 和 Dependabot 对 SCA 有很好的覆盖。

右移，生产运行时

• DAST 工具是作为 Web 应用程序扫描器构建的，旨在查找注入漏洞、身份验证缺陷和错误配置，而不是查找已提供服务的响应中的硬编码凭据。
• 运行时密钥扫描的专用工具有限。

这并非对DAST工具的批评。它们解决的是另一个问题。硬编码在压缩后的webpack包中的Azure AD凭据看起来不像注入漏洞。它们不会触发XSS漏洞检测。它们不会出现在DAST报告中。对于整个Shift+Right工具类别来说，它们是不可见的，因为该类别的设计初衷并非为了发现它们。

一旦某个秘密绕过了左移控制并进入生产流程，它就会从所有扫描仪的视野中消失。

如今，只有三个渠道能够找到这些凭证。

• 一位仔细阅读 JavaScript 代码的手动渗透测试人员
• 安全研究员或漏洞赏金猎人
• 攻击者

这三人中有两人汇报了他们的发现，一人没有。

现有工具的攻击面缺失

要了解DAST为何保持沉默，关键在于了解它究竟忽略了哪些方面。现有的工具并不能覆盖现代Web应用程序的实际攻击面：

• 使用 React、Vue 或 Angular 构建的单页应用程序，其整个应用程序是一个经过压缩的 webpack 包，被分割成数十个 chunk 文件。
• 加密配置对象中，客户端加密库使用硬编码在同一文件中的密钥解密配置块——解密密钥与密文相邻，使得加密失去意义，完整的凭据集随时可能泄露。
• 扫描 HTML 源代码以查找 SSR 状态 blob——即 Next.js 和 Nuxt 注入到 HTML 中的 __NEXT_DATA__ 或 window.__INITIAL_STATE__ 对象，这些对象通常包含令牌和内部配置信息。
• JSON API 响应中返回的凭据字段原本不应该面向客户端。
• 企业服务返回的XML 响应包含连接字符串和服务凭据
• 每个出站 API 调用的请求头都以明文形式携带订阅密钥和持有者令牌。

按回车键或点击查看完整尺寸的图片

查看源代码：firebase.js 服务帐户

关键在于，它们都缺乏足以满足实际应用需求的噪声抑制功能。如果一个工具每次扫描都会产生数百个误报，那么它最终会被禁用。噪声抑制功能决定了检测结果是否会被采纳或忽略。

在 CI/CD 中部署前扫描构建产物可以弥补部分缺陷。它可以捕获管道变量替换中嵌入的敏感信息，防止它们进入生产环境。但它无法覆盖应用程序部署后加载的运行时配置、从 CDN 动态提供的延迟加载数据块，或者嵌入在第三方脚本中、从未触及构建管道的凭据。产物扫描是一个有用的层，但它并非运行时层。

大局观

业界在技术左移方面所做的投入是真实、合理且有价值的。在部署前发现秘密永远比部署后发现要好得多。

但秘密信息仍然会流入生产环境。它们之所以能绕过控制，并非因为工具本身存在缺陷，而是因为从开发到部署的路径分支众多，任何单一的扫描层都无法覆盖所有分支。一旦秘密信息到达运行时层，现有的工具就束手无策了。

在左移扫描方面投入了数百万美元。但在右移扫描方面，却没有专门制造的生产级工具。

两项独立研究证实了互联网规模的这一现象。

2025年12月，Intruder发布了一项研究，扫描了约500万个应用程序，并识别出约42000个暴露的令牌。这项研究证实了此类攻击在互联网规模上的普遍性，并表明标准的DAST和基础设施扫描器无法覆盖这一范围。

2026年初，Demir等人于arXiv上发表了题为“门垫上的钥匙”（Keys on Doormats）的学术测量研究。该研究抓取了公共网络上的1000万个页面，并提取了1748个不同的凭证。其中84%的凭证嵌入在JavaScript代码中。凭证的中位数在网络上持续存在了12个月。该研究涵盖了14家云服务和SaaS提供商。不同的方法，相同的结论：互联网规模下运行时层未被扫描，凭证的存留时间足以被发现和滥用。

本文中的链接展示了攻击者读取这些凭证后可以解锁哪些内容。这些模式如今已出现在服务于真实用户的生产应用程序中。两个目标都启用了密钥扫描，但都没有运行时覆盖。

攻击者早已知道这一点。大多数安全团队目前还没有应对之策。

今天您可以查看什么

对于安全团队来说，最直接的检查方法很简单。在自己的生产应用程序中打开开发者工具，转到“网络”选项卡，查看正在传输的内容。检查 JavaScript 包的源代码、API 响应负载和请求头。特别注意配置对象中是否存在类似 client_id、client_secret、AppKey、SubscriptionKey、apiKey 或任何高熵字符串的模式。无需任何工具。你十分钟内发现的东西，攻击者十分钟内也能发现。

如果您的组织运行与 Azure AD 和 APIM 通信的 Angular 或 React 单页应用程序 (SPA)，那么十分钟的 DevTools 检查是本周您可以进行的最有价值的安全审查。

为什么现有工具无法弥合差距

运行时扫描类别并非空白。此时，持怀疑态度的读者可能会问：哪些现有工具已经涵盖了这方面的内容，哪些又没有？

像 GitLeaks、detect-secrets 和 GitHub Advanced Security 这样的代码库和文件扫描器已经非常成熟且部署完善。它们扫描的是源代码控制系统中的内容，而不是应用程序在运行时提供的内容。

TruffleHog独树一帜。它扫描代码仓库和文件系统，通过 HTTP 源接收 URL 列表，并验证发现的凭据是否有效，而大多数扫描器并不具备这项功能。无论是指向已下载的 JavaScript 包还是 URL 列表，它都能很好地处理这些输入。但它不会将运行中的应用程序视为黑盒，捕获应用程序运行时提供的所有信息。动态加载的代码块、JSON 和 XML 响应体以及实际执行过程中出现的请求头等信息，都会被保留在 URL 列表输入之外。

像 Cariddi、SecretFinder、LinkFinder 和 jsleak 这样的主动爬虫会抓取 JavaScript 文件，并对其中的内容进行正则表达式匹配。它们适用于应用程序的公开接口。这些爬虫是静态抓取工具，它们不会观察应用程序的实际运行情况，也不会捕获 API 响应体、请求头或仅在实际执行期间才会出现的延迟加载数据块。

像 Nuclei 这样的模板扫描器利用社区泄露的秘密模板，攻击特定的 URL 并进行正则表达式匹配。它们依赖于预先知道的 URL 以及模板的维护。它们并非被动地观察应用程序提供的任何服务。

像 OWASP ZAP、Burp Scanner 和类似的商业DAST 扫描器会查找注入漏洞、身份验证缺陷和配置错误。它们并非旨在查找已提供响应中硬编码的凭据，而且它们也无法做到这一点。

每个类别都解决了一部分问题。但它们都无法实现运行时凭证泄露真正需要的组合。必须同时具备四个属性。

• 黑盒操作。无需源代码，无需 API 文档，也无需事先了解应用程序。该工具能够像外部攻击者一样进行操作。
• 观察运行时流量。包括JS 包、JSON 和 XML 响应体、请求头、HTML SSR 状态块以及动态加载的数据块。也就是应用程序运行时实际提供的所有内容。
• 检测加密数据块结构。CryptoJS风格的解密密钥硬编码在密文旁边。仅扫描明文的扫描器会直接忽略这些结构。
• 激进的噪声抑制。运行时流量充斥着 UUID、缓存清除器和高熵字符串，这些都不是凭据。如果一个工具每次扫描都会产生数百个误报，那么它会在一周内被禁用。

如果这四者不能同时使用，该工具要么无法实现应用程序实际提供的功能，要么会产生过多的噪音而被关闭。

四层防御

披露的信息和后续研究都指向同一个安全漏洞：进入生产环境的密钥在运行时层没有经过扫描。弥补这一漏洞并非一朝一夕之功，而是一个四层防御体系：两层预防，两层检测。

预防：

[1] 后端前端 (BFF)。结构性解决方案。凭证永远不会进入浏览器。前端仅向 BFF 服务器发送会话 cookie，BFF 在运行时从存储库中获取凭证，并代表用户调用上游 API。如果凭证从未离开服务器，则不会从浏览器泄露。

按回车键或点击查看完整尺寸的图片

当前架构与 BFF 模式

BFF 是正确的目标，但这并非一朝一夕就能完成的。前端目前使用这些凭证与后端通信。移除这些凭证会直接导致应用程序崩溃。真正迁移到 BFF 意味着要搭建一个服务器端代理，将 SPA 的所有 API 调用都重新路由到该代理，将浏览器中的 bearer token 身份验证替换为会话 cookie，并重构 CORS、CSRF 以及应用程序当前使用的任何 WebSocket 或服务器发送事件路径。对于一个规模较大的 SPA 来说，这将是一个需要跨越多个季度、涉及前端、后端、身份验证和基础架构团队的复杂项目。在迁移过程中，凭证将保留在浏览器中。在结构性修复完成之前，底层的检测层将承担相应的负载。

[2] 密钥管理器和短期令牌。Azure Key Vault、AWS Secrets Manager、HashiCorp Vault。BFF 在运行时读取凭证，为下游调用生成有效期短、作用域有限的令牌，并且绝不会在客户端可访问的任何位置嵌入长期密钥。从浏览器泄露的短期令牌仍然会泄露信息，但其影响范围受限于令牌的过期时间和作用域，而不是受限于硬编码的客户端密钥的生命周期。

检测：

[3] 构建和部署之间的工件扫描。这是一个 CI/CD 作业，它会在打包工具运行后、工件发布前扫描 dist/ 目录下的输出。它可以捕获构建时注入到 bundle 中的凭据，这些凭据不会触及代码仓库。大多数流水线都包含第一阶段的源代码扫描，但缺少第二阶段的工件扫描。添加工件扫描是一个 CI/CD 作业，而不是一个项目。

按回车键或点击查看完整尺寸的图片

包含工件扫描阶段的 CI/CD 流水线

[4] 运行时秘密扫描。被动观察已服务的流量。这是唯一能够捕获响应头中延迟加载的数据块、SSR 状态、运行时获取的配置和凭据的层。这些信息仅在执行期间才会出现，无法从静态源文件中预测。

第 1 层和第 2 层负责移除表面凭证。第 3 层和第 4 层负责拦截漏网之鱼。与其等待防御措施先到位，不如同时启动所有四层：第 3 层和第 4 层可在几天内部署，第 2 层可在几周内部署，第 1 层可在几个季度内部署。检测层的作用是在防御层构建期间保护您。目前大多数组织仅部分运行第 1 层，完全跳过第 2 层和第 3 层，并且没有针对第 4 层的解决方案。

缩小运行时差距

我正在继续开发第四层（网络层）的SecretSifter，这是一个开源的被动式运行时密钥扫描器，它可以读取 HTTP 流量，获取左移工具无法识别的凭据。它以 Burp Suite 扩展、浏览器扩展和桌面应用程序的形式发布。

按回车键或点击查看完整尺寸的图片

SecretSifter调查小组

• github.com/secretsifter/secretsifter-burp
• github.com/secretsifter/secretsifter-extension
• github.com/secretsifter/secretsifter-desktop

尝试自行完成演示

本文中的截图和流程链均可在InsecureShield上进行端到端复现。InsecureShield 是一个故意设置漏洞的保险门户网站，发布在github.com/secretsifter/insecureshield-demo。以上截图中的所有凭证、端点和响应均来自该公开演示。这些凭证是合成的，并且已经过针对其真实提供商的身份验证测试，确认无法使用。

逐步演练，从查看源代码到代币铸造再到数据泄露，两条链的操作步骤都可以在docs/reproduction-guide.html存储库中找到。

git clone https://github.com/secretsifter/insecureshield-demo
cd insecureshield-demo
npm install
npm start

#

• 

  

  

• 公众号:安全狗的自我修养

• vx:2207344074

• http://gitee.com/haidragon

• http://github.com/haidragon

• bilibili:haidragonx

• 

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：安全狗的自我修养 haidragon haidragon《账户劫持链-流传至今的秘密》