Magecart 是什么？网店如何防范，从银行卡到 Pix

Magecart 指的是一类攻击：把恶意代码植入正规网店的付款页面，截走顾客输入或支付的内容。多年来，攻击目标一直是银行卡号。2026 年 9 月，巴西的一场攻击活动显示，同类代码已经开始替换 Pix（巴西中央银行推出的即时支付系统）的二维码。商店照常运营，品牌没错，价格没错，顾客看不出任何异常。

名称的由来

这个名字由 Mage（取自 Magento）和 cart（英文的购物车）组合而成。上个十年中期，研究人员开始用它称呼攻击该平台购物车的团伙。后来，这个词渐渐指代这种手法本身，不论是哪个电商平台，是自建商店还是第三方服务。

判断一次攻击是否属于 Magecart，看的不是所用的工具，而是位置：顾客填写付款方式的那个页面。

Magecart 攻击如何运作

1. 入侵。 代码通过平台未修补的漏洞、有漏洞的插件或主题、泄露的后台密码，或被攻陷的第三方脚本进入。2024 年 6 月，一个被超过 10 万个网站使用的脚本服务在易主后开始分发恶意代码。
2. 伪装。 这段代码通常只有几行，经过混淆，藏在合法文件、图片，或商店本已信任的服务里。2026 年 4 月，研究人员在约 100 家网店中发现代码藏在一张不可见的图片里。同年 6 月，另一个家族把代码和窃取的数据存放在一个知名支付服务内，让流量看起来一切正常。
3. 只在结账时动手。 在其他页面，代码保持静默。顾客一进入付款环节，它就读取信用卡或借记卡的输入框，或者替换二维码、Pix Copia e Cola（顾客复制后粘贴到银行应用里的文本付款码），或 boleto（巴西银行付款单）的 linha digitável（boleto 上的付款编号）。
4. 得手。 如果是银行卡，数据会被发送到攻击者的服务器，日后再用。如果是 Pix，是顾客自己当场把钱转进了错误的账户。

定义这个问题的案例

• British Airways，2018 年。 网站和应用中一个被篡改的脚本，在大约两周内复制了支付数据。英国数据保护机构统计共有 429,612 人受影响，并于 2020 年 10 月处以 2,000 万英镑罚款。
• Europol，2023 年。 一次由 Europol（欧洲刑警组织）协调的行动，通知了多个国家的数百家网店：它们的付款页面上运行着窃取银行卡数据的代码，其中大多数商店对此毫不知情。
• 2026 年。 当年的研究显示，代码正转移到常规防护不会检查的地方：图片内部，以及正规支付服务内部，商店很少去那里找。
• 巴西，2026 年 9 月。 网名 eremit4 的独立研究人员发现、Kaspersky 确认了 90 家中小型网店，其结账页面上的代码会替换二维码和 Pix Copia e Cola。顾客选择银行卡付款时，同一段代码会复制卡片资料。这位研究人员称之为“巴西版的新 magecart”。我们在Pix 版 Magecart中详细介绍了这个案例。

为什么商店迟迟察觉不到

银行卡付款时，交易获批，钱也到账了。损失要几周后才在顾客的账单上出现，而且只有发卡行把多起案例对照起来，才会得出结论：这些人都在同一家店买过东西。

Pix 付款时，钱根本没进来。后台显示订单待付款或已放弃，几天后商品没有发出，投诉才来。2026 年受害的商家最先注意到的是弃单增多，之后才弄清到底发生了什么。

无论哪种情况，服务器都可能看起来很干净。如果代码来自外部，或在浏览器里拼装，商店文件的副本不会有任何变化。变的是顾客看到的内容。

PCI DSS 的要求

自 2025 年 3 月 31 日起，PCI DSS 的 6.4.3 和 11.6.1 两项要求对所有在线接受银行卡的商家强制生效。6.4.3 要求为付款页面的脚本建立清单，每个脚本都要有理由，并确保其完整性。11.6.1 要求有一种机制，能发现页面和安全响应头的未授权改动，并至少每周检查一次。

这两项要求是因银行卡 Magecart 而制定的。它们没有提到 Pix，也没有提到 boleto，尽管替换二维码的代码运行在同一个页面上，走的也是同一条路径。关于这两项要求，参见PCI DSS 合规。

如何保护网店免遭 Magecart 攻击

1. 堵住入口。 更新平台、主题和插件，删除不用的部分。大多数攻击活动利用的都是已知且已修复的漏洞。
2. 保护后台。 所有管理员启用双重验证，检查有访问权限的账户，并更换各项集成的密码。
3. 精简结账页面上运行的内容。 付款页面上的每个脚本都要有负责人和理由。在线客服、热力图和广告像素很少需要放在那里。
4. 优先使用支付服务商托管的银行卡输入框。 它们能降低数据被直接复制的风险，但周围的页面仍可能显示一个假表单。
5. 限制页面能把数据发往哪里。 配置得当的内容安全策略，能阻止数据发往陌生的服务器。但如果攻击者利用的是商店已经放行的服务，它就帮不上忙。
6. 以顾客看到的样子监控页面。 服务器上的文件可能没问题，屏幕上的内容却可能有问题。参见如何监控结账页面的改动。
7. 核对显示的付款码。 对于 Pix、boleto 和稳定币钱包，在顾客付款前，把屏幕上显示的内容与商店签发的内容进行比对。
8. 为事发当天准备预案。 谁来关闭受影响的支付方式，谁联系服务商，如何通知顾客，如何保存证据。

商店可能已经中招的迹象

• Pix 待付款增多，结账页面的访问量却没有相应下降。
• 顾客说已经付款但订单没有通过，凭证上的收款方是别的公司。
• 支付服务商或收单机构通知，有银行卡在本店消费后被用于欺诈。
• 没人发布过任何内容，文件却被改了，或者出现一个没人认识的管理员。
• 付款页面把数据发往团队不认识的域名。

如果同时出现两个迹象，在证明不是之前，都按安全事件处理。

Proteside 的作用

Proteside 是一层网络安全防护，在付款人的屏幕上核对支付数据是否就是卖家签发的那一份，并在确认前拦截替换。它能建立 PCI DSS 要求的脚本清单，而且做得更多：在每笔订单中，把二维码、Copia e Cola、linha digitável 和银行卡表单与商店生成的内容进行比对，并把每次尝试记录为证据。参见它针对信用卡的运作方式，以及PCI DSS 合规。