- 一种新型的读卡器利用加密的 WebRTC 数据通道窃取银行卡信息，绕过 CSP 和以 HTTP 为中心的控制措施。
- Magento 和 Adobe Commerce 中的 PolyShell 漏洞使得窃取器更容易被注入到结账过程中。
- 窃取工具已经从 HTTP 和图像信标发展到 WebSocket，现在又发展到 WebRTC，其隐蔽性也随之增强。
- 防御需要快速修补漏洞、脚本监控和支付表单行为监控。
一种基于 WebRTC 的新型信用卡窃取器正在颠覆电子商务平台的安全机制。这种恶意软件可以直接从客户的浏览器中窃取支付数据，并利用 WebRTC 数据通道将其从网站提取出来，巧妙地绕过了内容安全策略 (CSP) 或仅监控 HTTP 流量的传统 Web 应用防火墙 (WAF) 等安全机制。
这种方法不仅巧妙，而且还利用了Magento和Adobe Commerce中的PolyShell等关键漏洞，这些漏洞允许未经身份验证的攻击者上传恶意代码并在服务器上执行。其结果是极其危险的组合：轻松入侵系统、在结账时静默注入脚本，以及利用基于UDP的WebRTC DTLS窃取信用卡信息，而这几乎对大多数现有防御措施都是不可见的。
这项发现的幕后推手是谁？它为什么如此重要？
专注于保护电子商务平台的网络安全公司Sansec发现了这种新型WebRTC窃取器。他们的工作重点是分析在线商店中的恶意软件事件，定位代码注入、支付窃取器和后门，并提供专注于电子商务的威胁情报。
此案意义重大，因为它首次记录了利用 WebRTC 数据通道在电子商务环境中窃取信用卡数据的案例。此前，类似 Magecart 的犯罪团伙主要依赖传统的 HTTP 请求、图像信标，或者在更高级的场景中使用 WebSocket。这一突破性的进展可谓颠覆性的。
Sansec并非在孤立的实验室中偶然发现这一技术，而是在调查大型企业发生的真实攻击事件时得出的结论。受影响的目标包括一家市值超过1000亿美元的汽车制造商、一家位列全球前十的连锁超市以及其他数十亿美元的公司。换句话说，攻击者正在改进其技术，以直接攻击最具价值的目标。
短短两个月内，研究人员就在五个同等级别的组织中发现了窃听器，这进一步证实了这并非一次性实验，而是一种明显的趋势，即采用更隐蔽、更难用常规工具检查的技术。
窃取器的工作原理：WebRTC 数据通道作为一条秘密高速公路
在大多数传统的盗刷事件中，脚本都相当为人所知：攻击者利用配置错误、易受攻击的插件或被入侵的第三方脚本注入代码，捕获支付表单数据并将其发送到外部站点，通常是通过 HTTP POST 请求发送到他们控制的服务器。
虽然这类流量令人厌烦，但通常可以通过 Web 应用防火墙 (WAF)、入侵检测/入侵防御系统 (IDS/IPS) 规则、深度包检测或精心调校的云安全策略 (CSP) 来检测。然而，当一段 JavaScript 代码突然出现，试图通过 HTTP 协议向一个陌生的域名发送信用卡信息时，就应该提高警惕了。问题在于，这个新的窃取程序决定彻底改变其通信渠道。
该恶意软件不使用 HTTP 或 WebSocket，而是建立RTCPeerConnection ，在受害者的浏览器和攻击者的基础设施之间创建 WebRTC 数据通道。流量以数据报的形式通过 UDP 传输，并使用 DTLS（数据报 TLS）加密。对于许多安全工具而言，这几乎只是加密的网络噪声，难以进行特定解读或过滤。
这样一来，窃取器既可以通过 WebRTC 通道本身接收恶意载荷（从而避免通过 HTTP 加载可疑脚本），又可以通过同一通道窃取结账时捕获的信用卡信息。所有这些操作都不会产生分析师在检查服务器日志、代理或防火墙时通常会寻找的典型网络流量痕迹。
这好比你用摄像头和警报器监控自家前门，而入侵者却能从侧窗轻松进出。如果安全措施仅仅关注HTTP/HTTPS流量，就无法真正了解这些加密的点对点连接，除非部署高度专业的WebRTC分析工具或浏览器行为监控系统。
内容安全策略：它保护了什么，以及它在 WebRTC 方面的不足之处
内容安全策略(CSP)已成为保护现代 Web 应用程序的关键组成部分。本质上，它允许您从服务器端定义浏览器可以连接到哪些域以及允许使用哪些资源（脚本、图像、字体等）。
connect-src、script-src 和 img-src等指令有助于限制出站请求和从不受信任的来源加载代码。如果配置严格且不使用过多通配符，正确使用 CSP 可以显著降低脚本注入攻击和通过 HTTP 或 WebSocket 进行数据泄露的影响。
主要漏洞出现在 WebRTC 应用中。目前的标准缺乏广泛采用的 CSP 指令来规范 RTCPeerConnection及其数据通道。实际上，即使有人为 HTTP 连接定义了非常严格的策略，恶意代码仍然可以与攻击者的服务器建立点对点连接，并通过该连接发送加密数据。
Chrome 有一个针对 WebRTC 的实验性 CSP 指令，但其使用范围仍然有限，并且并非大多数网站的标准安全措施之一。这就造成了一个明显的漏洞：仅仅基于 CSP 的安全措施会给人一种虚假的保护感，而当脚本能够建立直接的 WebRTC 连接时，这种保护感就无法反映现实。
简而言之，许多在线商店认为，由于他们屏蔽了除少数白名单域名之外的所有外部域名，因此他们的政策“万无一失”，但他们仍然将客户数据暴露给这些通过常规规则未涵盖的渠道运作的窃取者。
恶意软件如何利用CSP nonce来伪装自己
一些开发者更进一步，在 CSP 标头中使用 nonce 值。这种方法是将一个随机值（nonce）分配给每次页面加载，并将其添加到 CSP 策略和文档中的合法脚本中，这样只有携带该 nonce 值的脚本才会被执行。
理论上，这使得攻击者难以简单地将外部脚本注入页面，因为此类脚本缺少正确的 nonce 值，会被浏览器拦截。然而，已发现的 WebRTC 窃取器表明，该 nonce 值也可以在浏览器内部被窃取或重复使用。
该恶意软件会分析网页代码，找到包含随机数的合法脚本，并将其复制到自身的代码块中使用。这样，恶意脚本就能以与合法脚本相同的“身份”出现在浏览器中。
当这种情况发生时，监控工具和网站自身的策略都无法区分合法代码和注入代码，因为两者似乎都符合相同的安全要求。一旦通过了这一层过滤，窃取程序只需初始化 RTCPeerConnection，打开数据通道，即可开始交换加密数据而不引起怀疑。
主要问题在于，大多数网络安全解决方案都侧重于检查HTTP协议，最多也只检查WebSocket协议。而这种窃取器完全绕过了这些层级，因此不会产生任何明显的异常HTTP请求来暴露窃取行为，这大大增加了事件响应和后续取证的难度。
Magento 和 Adobe Commerce 中的 PolyShell：完美的入口
如果攻击者没有有效的方法将他们的代码注入到应用商店中，那么所有这些设置都将毫无意义。而PolyShell正是利用了这一点，它是 Magento 开源版和 Adobe Commerce 中的一个严重漏洞，已成为这种 WebRTC 窃取器的主要入口点。
PolyShell 允许未经身份验证的攻击者将潜在可执行文件上传到特定服务器路径，尤其是在媒体目录配置未得到适当加固的情况下。攻击者可以利用这些上传的文件部署 Web Shell、后门以及各种旨在执行任意代码的脚本。
最早的大规模利用迹象可以追溯到2026年3月19日，当时检测到大量来自50多个不同IP地址的自动化扫描。这些扫描专门针对存在PolyShell漏洞的Magento和Adobe Commerce实例。
研究人员收集的数据显示，约有56,7%被认定为存在漏洞的商店在极短时间内遭到攻击。如此高的比例表明，攻击者已将漏洞利用自动化程度极高，并将其转化为大规模攻击。
一旦代码执行成功，犯罪分子就会将窃取信息脚本注入到结账逻辑中，这样当客户输入支付信息时，代码就会自动运行。此后，通过 WebRTC 进行的信用卡信息窃取和数据外泄将持续进行，直到安全漏洞被发现并彻底清理系统环境为止。
Magecart 的演变和向 WebRTC 的飞跃
多年来，各种以窃取在线商店支付数据为目标的犯罪分子和活动都被归类为 Magecart。它并非一个单一的组织，而是一类随着行业安全措施发展而不断演变的策略和工具。
早期，窃取器只需向攻击者控制的域名发送HTTP请求即可。如果公司部署了Web应用防火墙（WAF）或审查了访问日志，这些模式就相对容易被识别，这促使犯罪分子寻求更隐蔽的替代方案。
随后出现了图像信标技术，这种技术将窃取的信息嵌入到看似无害的图像上传参数（例如 GIF 动画）中。虽然这种技术更为隐蔽，但通过适当的规则和出站流量分析仍然可以检测到。
后来，一些组织开始使用WebSocket 在浏览器和命令控制服务器之间维护持久通道。这种方法使得针对传统 HTTP 流量的工具更难检测，但对于那些检查连接标头和目标地址的人来说，它仍然可见。
当前向 WebRTC 数据通道的转变，实际上是对这场军备竞赛的合乎逻辑的回应。攻击者利用专为视频通话、聊天或实时流媒体设计的标准，可以将自己伪装在加密且去中心化的数据流背后，而这种数据流在企业环境中往往难以得到有效监控。
传统窃取器与基于 WebRTC 的窃取器
将传统的窃取器与这种新的 WebRTC 方法进行比较，主要区别之一在于提取数据所使用的通道。前者依赖于 HTTP/HTTPS 或 WebSocket，而后者则使用通过数据通道传输的、经 DTLS 加密的 UDP 数据。
另一个关键区别在于安全工具的可见性。Web应用程序防火墙（WAF）、反向代理，甚至网络入侵检测系统通常都能很好地识别和记录恶意HTTP流量，但却难以检查加密的WebRTC通道的内容。
第三个主要区别在于内容安全策略 (CSP) 的作用。在传统方案中，精心设计的内容安全策略可以通过限制与未知域的连接来阻止许多非法数据外流。然而，在 WebRTC 中，标准 CSP 无法控制 RTCPeerConnections 的创建，这使得窃取者几乎可以毫不费力地绕过这一屏障。
最后，还有防御成熟度的问题：安全团队和解决方案提供商多年来一直在完善用于检测异常HTTP流量的签名、规则和机制，但在应对电子商务环境中的WebRTC滥用方面，仍然缺乏同等水平的专业知识。目前，时间上的不对称性对攻击者有利。
使用 WebRTC 的防窃取措施
鉴于这种情况，人们很容易认为无能为力，但事实并非如此。一系列措施结合起来，可以显著降低此类盗刷器被安装并隐藏在您的网店中的可能性。
1. 立即应用 Magento 和 Adobe Commerce 补丁
第一步是解决问题的根源，也就是入口漏洞。如果您的企业使用Magento 开源版或 Adobe Commerce，那么务必检查当前版本，并在 PolyShell 漏洞的补丁程序发布后立即安装到生产环境中。
报告显示，超过一半检测到的易受攻击的系统（具体而言，占门店总数的 56,7%）在短时间内遭到入侵。继续使用旧版本或推迟打补丁，无异于拿客户数据玩俄罗斯轮盘赌。
2. 监控脚本的完整性
由于窃取程序主要注入到结账脚本中，因此最有效的防御措施之一是部署JavaScript 完整性监控工具。电子商务安全提供商提供的解决方案等可以检测到未经授权的代码更改。
这些平台会将您当前文件的状态与参考版本进行比较，并在出现新的、混淆的或重定向的区块时发出警报。虽然没有任何工具是万无一失的，但这种监控方式可以大幅缩短窃取程序能够持续活动而不被发现的时间窗口。
3. 探索面向 WebRTC 的 CSP 指令的使用
虽然仍处于实验阶段，但一些浏览器（例如 Chrome）已开始支持针对WebRTC 的特定 CSP 指令。如果您的受众主要使用现代浏览器，并且您对相关技术栈有较好的了解，那么探索这些选项或许是值得的。
然而，将所有信任寄托于尚未标准化或未得到统一支持的功能是不明智的。理想情况下，它应该被视为额外的安全防护层，而非唯一的防护层，还需要结合积极的补丁更新、脚本分析和良好的依赖管理实践。
4. 审查并减少第三方脚本
您加载到商店中的每个外部脚本都可能成为攻击点。客户服务组件、分析工具、广告平台或第三方库，如果其中任何一家提供商遭受攻击，都可能成为恶意代码注入的渠道。
一个合理的措施是定期（例如每三个月一次）审核所有加载在敏感页面（例如结账页面）上的脚本，并移除那些并非绝对必要的脚本。依赖项越少，攻击面就越小。
5. 实时监控支付表单的行为
除了静态检查代码之外，监控支付表单在运行时的实际行为也非常有用。这包括记录它尝试向哪些域发送数据、是否打开了意外的连接，或者是否在没有功能性理由的情况下发起了 RTCPeerConnection 连接。
一些网站托管和安全服务提供商为关键表单提供实时行为分析功能。一旦检测到试图将数据泄露到未经授权的域名或使用异常通信渠道的行为，系统即可终止可疑会话、阻止 IP 地址，并立即通知安全团队。
常见的错误会给机会敞开大门。
实际上，许多涉及此类窃取器的事件都反映出受影响组织存在一些反复出现的问题。关注这些问题有助于避免重蹈覆辙。
1. 盲目信任非常严格的云服务提供商 (CSP)。
设置严格的CSP固然是好事，但这并非万全之策。由于标准版CSP无法控制RTCPeerConnection，即使所有未经授权的HTTP连接都被阻止，攻击者仍然可以通过WebRTC窃取数据。
因此，认为“既然我已经部署了内容安全策略 (CSP)，就能抵御所有通过浏览器进行的操作”是错误的。如果没有包含 Web 应用防火墙 (WAF)、脚本监控、日志审查和定期安全审计等多层防护措施，单靠内容策略无法有效应对我们正在讨论的这类技术。
2. 延迟修补已知漏洞
另一个常见的错误是，当发现存在公开利用的严重漏洞时，未能及时更新。PolyShell 就是一个典型的例子，它说明了当组织反应迟缓时，一个已知漏洞（即使有详细信息）是如何被大规模利用的。
一旦漏洞被列入CISA的已知利用漏洞（KEV）等目录中，其补丁优先级就应该大幅提升。在这种情况下，继续在生产环境中使用过时的版本或不应用热补丁，无异于明知故犯地承担极高的风险。
3. 仅依赖网络监控
许多基础设施都拥有强大的系统来检查 HTTP、HTTPS 和 TCP 流量，但对于加密的基于 UDP 的通信（例如 WebRTC 使用的通信）却几乎一无所知。这会造成一种虚假的控制感：仪表盘显示一切正常，而窃取者却可以通过其他渠道进行通信。
该解决方案是在传统网络监控的基础上，增加代码完整性监控和客户端行为分析。换句话说，不仅需要关注网络上传输的数据，还需要关注浏览器中运行的 JavaScript 代码的行为以及它如何与 WebRTC 等 API 进行交互。
哪些是确定无疑的，哪些又是尚未确定的。
公开的有关此窃取器及其相关活动的信息使我们能够区分已确认的事实和仍处于合理推测灰色地带的方面。
已确认的发现包括：在一家大型汽车制造商的在线商店中发现了正在运行的 WebRTC 窃取器；PolyShell 于 2026 年 3 月 19 日开始大规模攻击；以及约 56,7% 的易受攻击商店已被攻破。此外，还证实 WebRTC 数据通道不属于标准 CSP 指令的适用范围。
未经证实但合情合理的方面是，所有受影响的主要公司的身份尚未确定，因为并非所有公司都已公开点名。此外，目前还不清楚使用 WebRTC 作为数据泄露渠道是否正在变得普遍，或者目前是否仅限于某些拥有高超技术能力的组织。
同样，这种攻击手段的细节、恶意软件可能包含的辅助模块，以及它与攻击链其他组件的集成程度，目前尚未完全明了。可以合理推断，像WordPress或Magento这样的安全解决方案提供商，正在努力改进其针对这种特定模式的检测引擎。
关于WebRTC电子商务窃取器的常见问题
这类威胁的出现引发了在线商店管理员和安全专家的诸多疑问。有些问题反复出现，因此最好直接解答。
如何判断我的店铺是否安装了盗刷器？
最有效的方法是使用能够扫描网站代码以查找可疑模式、混淆脚本、恶意域引用或对结账流程的未经授权更改的工具。
如果您的主机提供商包含托管安全服务，建议您尽快进行全面扫描。就 PolyShell 漏洞而言，您还应该确保您的 Magento 或 Adobe Commerce 实例已更新到修复该漏洞的补丁程序，并检查您的媒体目录是否存在任何异常或位置错误的文件。
如果 WebRTC 是一个合法的标准，为什么它还会被滥用？
WebRTC 的设计初衷是实现浏览器之间的实时通信：视频通话、屏幕共享、语音聊天和文件传输。但问题在于，任何足够灵活的通信渠道都可能被用于最初设计之外的用途。
在这种情况下，该标准默认情况下并未包含与云安全策略 (CSP) 的强大集成机制，从而造成了安全漏洞，攻击者已利用该漏洞。这与其说是一个具体的漏洞，不如说是一个设计上的缺陷，以及许多使用（或不使用）WebRTC 的 Web 应用程序缺乏配套的控制措施。
传统网络监控手段能否检测到这种攻击？
使用传统工具检测 WebRTC 通信内容并非易事，因为它们通过 UDP 协议使用 DTLS 加密传输。仅监控 HTTP/HTTPS 的 Web 应用防火墙 (WAF) 无法检测到网络中的网卡活动，就像传统防火墙在没有更多上下文信息的情况下也很难察觉到加密的 UDP 流量一样。
为了拥有真正的检测选项，必须结合 JavaScript 代码完整性分析、识别可疑 RTCPeerConnection 使用行为的行为规则，以及在某些情况下，高级加密流量检测解决方案，这些解决方案至少允许应用基于连接模式、目的地和流量的规则。
这个问题是Magento独有的，还是也会影响WordPress和其他内容管理系统？
公开描述的攻击途径与Magento 和 Adobe Commerce 中的 PolyShell 漏洞密切相关，但 WebRTC 数据窃取技术绝非这些平台所独有。任何允许在结账页面注入脚本的系统——包括 WordPress 及其 WooCommerce 或其他 CMS 平台——如果利用了不同的漏洞，都可能遭受类似的攻击。
换句话说，本案的特殊之处在于使用了 PolyShell 来获取访问权限，但使用 WebRTC 数据通道作为数据窃取渠道的做法适用于任何在支付过程中可以在客户浏览器中执行 JavaScript 代码的环境。
鉴于以上所述，很明显，随着 WebRTC 被用作数据泄露渠道，电子商务窃取策略取得了显著进展，攻击者利用了 PolyShell 等关键漏洞以及 CSP 等标准中的漏洞。管理在线商店的机构不能再仅仅监控 HTTP 流量并依赖单一的防护层：他们必须快速修补漏洞、缩小攻击面、监控脚本完整性，并密切关注浏览器中代码的实际行为，否则客户的支付数据最终可能会通过这个此前几乎无人关注的“侧窗”泄露。
