每次支付页面被改写背后都有一张看不见的网在收拢。安全圈最近都在盯一个叫 Magecart 的长期网络窃密活动它专门冲着全球支付网络下手。这不是某个小团伙临时起意而是一套已经运转很久、覆盖很多行业的数字窃密体系从注入恶意脚本到伪装成正常数据请求整个过程设计得相当精细。这篇文章想聊聊它到底怎么运作、为什么能藏这么久以及作为开发或者运维应该从哪些角度去自查和防御。Magecart 这个名字在支付安全领域不陌生它是针对在线商店结账页面的一种脚本窃取攻击的总称。攻击者会把恶意 JavaScript 注入到支付相关的页面里当用户填完卡号、有效期、CVV 这些敏感信息时脚本直接在浏览器端把这些数据带走用户毫无感知商户的服务器日志也往往看不出异常。最近这波活动之所以引起关注是因为它把攻击目标从单个网店扩展到了支付网关、第三方插件、供应链组件这些更底层的环节相当于从抢单个柜台升级成在运输通道上布设哨卡。这篇文章适合网站开发者、支付系统运维、安全运营人员以及所有使用第三方支付组件或前端脚本的团队来读。1. 活动画像这次攻击的核心特征与影响范围1.1 攻击者盯上的不只是结账页以往谈 Magecart大多关注的是商品详情页或者购物车页面的脚本注入。但这波活动有两个明显变化。第一攻击面扩大到支付网络本身恶意代码不再只藏在内联脚本里而是试图混进被广泛引用的公共服务脚本、统计脚本、客服组件里。只要某个被几百家站点共同引用的第三方脚本被攻破影响就不是单点而是辐射状的。第二攻击行为从“偷一把就跑”变成“长期潜伏、持续迭代”。有团队在样本分析日志里发现某些注入代码会和源站的脚本更新同步变化攻击者会跟随业务代码升级动态调整自己的载荷这说明他们在持续跟踪目标站点的开发节奏。这里涉及一个很核心的威胁模型购物环节的敏感数据在浏览器端输入经过 JavaScript 处理后被提交到商户后台或支付网关。如果浏览器端被注入了一段监听代码整个链路中最容易被信任、也最容易被忽视的“前端输入”环节就被劫持了。传统的 WAF 和服务端安全体系很难感知到这一点因为攻击者收集数据时用的还是正常接口、正常域名只是请求里多带了一些用户信息。1.2 长期窃密的三个典型特征从已披露的样本和多家机构的分析报告来看这轮攻击活动有几个非常明确的特征可以作为检测时的参考特征。第一个特征是域名策略。攻击者会注册和业务高度相似的域名或者是利用已被攻陷的合法域名来做回传。用相似域名是为了在浏览器开发者工具里看起来像分析服务用已被攻陷的域名则是为了提高信誉度让目标站点的安全审核不那么警觉。无论哪种方式外带流量的域名都在强调“像正常服务”。第二个特征是脚本加载时机。大多数版本会等到页面发生表单提交事件时才渲染完整载荷平时只存在一小段很轻量的“钩子”代码。这种方式让扫描器很难抓到完整恶意代码因为不触发条件的话看到的只有几行几乎不可读的变量声明。第三个特征是持久化方式。攻击者会在页面里注册定期检查逻辑每隔一段时间确认自己的注入点是否还活着。前端代码一旦被部署工具覆盖这个检查逻辑就会重新从远程拉取一份最新载荷并再次注入。也就是说单纯删除页面里的恶意标签往往治标不治本只要远程控制端还活着脚本就还会回来。2. 攻击链拆解从初始入侵到数据回传2.1 初始入侵供应链环节是最大的突破口每一次 Magecart 攻击都需要一个起点。根据对公开案例的整理初始入侵的常见路径有三类。第一类是供应链组件的失陷。站长未必直接中招但他使用的某个 Font Awesome 图标库、某个评论组件、某个在线客服插件如果托管在已被攻破的 CDN 或第三方服务上回源内容里就可能夹带恶意代码。由于这类资源在大量网站中共享攻击者每攻破一个热门组件就等于拿到了一份可以反复利用的万能钥匙。第二类是旧组件和插件漏洞。网上商店系统通常依赖大量插件比如折扣计算、库存同步、物流查询之类。这些插件的维护频率往往不高一旦被扫出高危漏洞攻击者就可以上传后门文件或者直接修改主题模板。很多攻击样本里都能看到针对已知 CVE 编号的利用痕迹说明攻击者是在批量扫描而不是手工定点。第三类是后台管理端口和凭证泄露。结账页面虽然在前端被注入但修改前端代码的入口通常在后台主题编辑器、插件文件管理器或者 FTP。如果后台地址没有做访问限制管理员口令又比较弱就会很容易被攻破。实践里我们遇到的很多案例攻击者都是先拿到一个低权限账号然后横向移动到能修改模板文件的权限。2.2 恶意脚本的注入与驻留方式注入点最常出现在这几个位置网站主题的 footer 文件、支付网关配置时加载的额外脚本区域、商品页的统一样式文件里。攻击者选择的逻辑很简单就是要找“每一个页面都会被加载”的公共位置而不仅是某个特定页面的私有位置。注入之后脚本通常不会立即暴露全部逻辑。一个典型的两段式结构是这样的第一段是初始化代码体积很小负责判断当前页面是否存在表单如果存在就动态创建 script 标签从远程地址拉取第二段代码第二段是完整采集器包含表单监听、键盘记录、数据处理与发送功能。将两段代码分离是规避静态扫描的常见手法。安全检查员看到的只是第一段很短的内容不触发加载条件的话第二段根本不会出现。驻留方面攻击者会在代码里加入定时器比如每 5000 毫秒检查一次注入节点是否还存在。如果前端构建流程重新部署了代码把恶意标签覆盖掉了这个定时器在下一轮检查时会发现自己的“家”没了于是再次创建节点拉取远程代码完成自我修复。这就是为什么很多团队清除了页面上的恶意脚本第二天却又看到它出现的原因。2.3 敏感数据如何被悄悄带走数据回传是整个攻击链里最能体现攻击者耐心的一环。先看采集对象。除了常规的卡号、有效期、CVV这波攻击活动还额外关注持卡人姓名、账单地址、邮箱地址、手机号、订单金额、商品明细。这不是单纯为了偷卡片数据而是为了拿整套身份信息去做后续的欺诈或撞库。采集数据的脚本会监听 input 事件的完整输入过程也就是记录用户的每一个按键而不是等表单提交才一次性读取。这种方式能有效规避那些只看表单提交事件的追踪逻辑。再看回传方式。攻击者会精心设计外带请求让它看起来像一次正常的页面统计或性能上报。常见的手法包括把敏感数据拼接在图片请求的查询参数里发往远程服务器用 POST 请求伪装成数据看板接口对采集到的数据进行 ROT13 或 Base64 编码后再传输。有些样本还会把数据切分成多段分别发送到不同域名、不同路径接收端再根据会话标识重组。这种拆分策略主要是为了规避基于流量大小的告警规则——如果单次请求里带的参数字符串异常大检测系统很容易发现但拆成几段每一段都像普通请求告警阈值就不容易触发。回传的时间和频率也有考究。有的脚本只在用户离开页面时发送一次有的则通过 setInterval 每 10 秒检查一次采集缓冲区一旦积累到一定数量立即发送。选择哪种策略取决于目标站点的流量环境。流量大的高并发站点脚本往往会保持低频、小包的特征流量小的站点反而可能一次性把整套数据打包带走。攻击者的目标始终只有一个——不被发现。3. 长期潜伏的隐身术代码混淆与行为规避3.1 多层混淆让代码读起来像一团乱麻安全团队在分析样本时最先感受到的技术压力往往来自混淆。这波恶意代码普遍采用多层混淆策略而且手法比较成熟。第一层是字符串编码。敏感的操作符、函数名、变量名被转成 Unicode 编码或十六进制运行时再通过解码函数还原。比如一个简单的设置 cookie 操作经过编码后看起来变成了一串毫无意义的数字和字母组合只有调用对应的解码函数才能还原为可读的代码。第二层是控制流平坦化。攻击者会把原本顺序执行的逻辑拆散放进一个个分支条件里再通过一个分发器变量控制跳转方向。这样做的效果是阅读代码时很难按正常逻辑顺序去追踪一条数据从采集到发送的完整路径。每一步都跳来跳去就像看一份被打乱的剧本。第三层是动态执行。使用 eval 或 Function 构造器来执行经过解码的代码让静态扫描工具很难在磁盘上看到完整的恶意逻辑。因为实际执行的内容是运行时才生成的文件系统里只有打包好的字符串和启动器。混淆本身不增加攻击能力但会显著消耗分析人员的时间。对防御方来说遇到高度混淆的脚本时与其逐行逆向不如从行为监控和网络外连两个维度去建立防线。3.2 行为规避躲在正常业务流量里高度混淆以外这轮攻击活动在行为层面也做得很精细。首先是不惊动登录用户。有些样本会检测 cookie 或 localStorage 里是否存在登录态标识如果检测到管理员正在后台登录就暂时不要执行采集逻辑。原因很现实管理员审查后台时如果发现卡号字段被监听问题会很快暴露。这种“避开猎人”的逻辑表明攻击者在用运营思维来指挥恶意代码。其次是不重复采集同一批数据。脚本会把已经发送过的表单指纹存进浏览器存储下次遇到同样的表单结构时直接跳过。表面上这是为了减少无效请求实际是在减小流量特征避免同一套数据反复外带被安全平台标记。再就是严格跟随机器的系统环境。部分复杂样本会先检测是不是无头浏览器、是不是安全沙箱环境只有发现自己运行在真实的用户浏览器时才释放完整载荷。这种反检测的对抗思路和安全分析团队使用的自动爬虫正好针锋相对。3.3 为什么能瞒这么久很多团队都会有同样的疑问为什么这类攻击往往运行数月甚至一年以上才被发现复盘下来几个原因比较现实。其一缺少前端依赖的清点。大部分站点的安全检测集中在服务端对页面最终加载的几十个第三方脚本没有完整的清单管理。新增一个未知脚本没有告警也没有审批流程。其二支付数据不在监控视线内。很多团队监控了数据库的异常读取、监控了后台的异常登录却没有监控浏览器向外部域名发送了什么。数据在到达服务端之前就被劫持服务端自然看不到任何异常。其三安全运营的疲劳。外带请求如果伪装成正常的数据上报和真实业务混在一起告警平台的噪音已经够大很难专门留意一个小周期的可疑请求。攻击者正是利用了这种运营疲劳把攻击节奏拉长放慢让自己变成背景噪音的一部分。4. 检测、排查与加固一份能直接落地的自查清单4.1 链路自查从浏览器端到服务端日志如果担心自己的站点可能受影响建议按下面几个方向逐项排查。先从浏览器端开始。使用浏览器开发者工具打开支付页面勾选“保留日志”按照正常流程填一遍表单并提交。然后逐一查看每次网络请求的发起方是哪个脚本文件特别关注那些域名和当前站点不一致、路径语义含糊的请求。接着在 Sources 面板里搜索关键词比如“addEventListener”“input”“localStorage”“cookie”看看是否有无关脚本在监听表单字段。对支付相关脚本可以搜索“card”“cvv”“expire”“pan”等关键字段重点判断它们出现的位置是否合理。再从服务端日志入手。结合接入层访问日志查找来自支付页面的外连请求中是否存在可疑域名的 POST 或 GET 记录。常见技巧是统计同一 IP 段发起外部请求的频率如果一个脚本以固定频率向同一域名发送数据包这种规整的时间序列在日志里相对显眼。另外可以检查请求参数里的字段名是否和业务参数能对上号正常业务请求的参数名语义明确比如 order_id、amount、callback恶意外带请求的参数名往往是随机生成的键值对。最后检查前端静态资源。把发布目录里的 JS 文件全部拉下来对比线上实际执行的脚本和仓库里的脚本是否一致。方法可以是对线上文件算一次哈希再跟本地构建产物比对。有一次排查时我们就是用脚本比对发现线上文件多出来 4 行代码而这 4 行代码被写在了压缩后的文件尾部肉眼几乎看不出来。4.2 关键防线CSP、SRI 与行为监控在加固层面有一些实践下来有效的措施可以直接落地。第一道是内容安全策略 CSP。为支付页面单独设置严格的 CSP把允许加载的外部域名白名单列出来不在名单里的脚本一律拒绝执行。具体操作上可以先把 CSP 设置为仅报告模式观察一段时间内的违规上报确认没有问题后再切换到强制拦截模式。需要注意CSP 不是配一次就一劳永逸业务会不停引入新的第三方组件每次改动都需要同步更新白名单。第二道是 SRI 完整性校验。对通过 script 标签加载的第三方静态资源在标签上加上 integrity 属性让浏览器在加载时计算文件哈希与标定的值不一致就拒绝执行。这个机制对防止 CDN 或上游资源被篡改非常有效。第三道是行为监控。部署在浏览器端的数据采集和风险分析工具时重点关注页面是否有异常的键盘监听器、是否有异常的 iframe 嵌套、是否有非白名单域名的数据外发。如果团队有自研的前端监控体系可以在页面卸载前对关键字段做一次脱敏推送只保留统计信息不记录原始卡片数据从源头上降低数据泄露的影响。4.3 供应链与权限加固的长期做法权限最小化不是一句口号而是需要落到账号、密钥、文件权限这些具体对象上。账号层面后台管理账号要启用二次验证并且不允许使用权限过大的超级管理员账号做日常维护。支付网关的密钥要存放在独立的密钥管理服务中不要写死在配置文件或前端代码里。文件权限方面模板目录和静态资源目录要遵循最小可写原则线上环境不允许通过后台在线编辑模板文件。如果业务必须在后台保留模板编辑能力也要把它限定在预发布环境线上只通过发布流水线更新。供应链管理方面建议建立一个前端依赖清单记录每一个第三方脚本的来源、版本、加载页面和用途。凡是清单之外的新增脚本都应当经过安全评审才能上线。这个方法执行起来不难但能把未知依赖挡在门外。很多时候攻击者能得手不是因为防线薄弱而是因为根本没人知道某个脚本什么时候被加进了页面。5. 常见问题速查与排查记录现象可能原因排查命令或方法处置建议支付页面出现无法识别的外连请求页面被注入 skimmer 脚本开发者工具查看请求发起方对比域名归属定位注入点删除恶意标签轮换支付密钥脚本文件与仓库不一致静态文件被篡改对线上文件做哈希与本地产物比对回收线上目录写入权限启用 SRI删除恶意脚本后下次又出现存在远程拉取和自修复逻辑全局搜索动态创建 script 标签的代码段同时阻断远程控制端域名再做清理后台账号异常登录凭证泄露或弱口令检查后台登录日志查看异常 IP 与时间强制重置口令启用二次验证第三方组件更新后页面异常上游组件被污染或配置错误对比新老版本代码差异回滚到可信版本建立组件审批流程数据包被拆分外带攻击者使用分段回传策略按时间窗口统计同一源 IP 的外发频率与包大小在接入层配置按会话维度的频率限制有一次在分析某电商平台的样本时我们发现了很有意思的一个细节恶意脚本特意避开了来自搜索引擎的流量因为它的采集目标是真实填写支付表单的用户而搜索引擎爬虫只会触发页面加载不会触发表单提交事件。这意味着攻击者对自己的采集对象做了精细的筛选不是把所有访问者都当成目标。这种精准让安全团队在流量日志里寻找异常时更加困难——它只挑最有价值的那些请求下手。另一次排查中我们反复确认代码里是否存在持续反向混淆最后发现只是 admin 后台的一个缓存插件把旧版本文件重新冲刷到了 CDN 节点上导致前端加载到了一个本该早已废弃的脚本版本。这件事的教训是排查异常脚本时不能只看发布仓库和线上文件还要检查中间层的缓存和 CDN 节点全链路的文件一致性才有意义。如果你所在团队此时还没有建立前端监控和第三方脚本清单建议把它列为下一季度的重点任务。攻击者潜伏得越长积累的受害者数据就越多恢复成本也变得越高。至少在支付相关页面尽早启动 CSP、SRI 和异常外连监测这三件事能拦住相当一部分已知类型的窃密攻击。Magecart 这类活动的演进速度非常快防御方唯一的策略是让自己的监控和响应速度跑在攻击者的迭代速度前面。