1. 项目概述当支付安全遇上WebRTC最近在分析一些安全事件时我注意到一个值得警惕的趋势利用WebRTC技术进行支付盗刷的脚本开始浮出水面。这听起来可能有点技术化但简单来说就是攻击者利用一个原本用于视频通话和实时通信的浏览器技术来绕过一些传统的安全验证直接操控受害者的支付流程。这不再是简单的钓鱼链接或者键盘记录器而是一种更隐蔽、更“自动化”的攻击方式。这类脚本的核心是滥用WebRTCWeb实时通信的P2P点对点连接能力。WebRTC本意是让浏览器之间能直接传输音视频和数据无需经过中心服务器中转这带来了低延迟和隐私保护的优势。但攻击者正是看中了这种“直接连接”的特性。他们可以构造一个恶意网页当用户访问时该页面通过WebRTC尝试与用户本地网络中的其他设备比如另一台用于支付的电脑或者同一网络下的手机建立直接连接。一旦连接建立攻击脚本就能像“远程遥控器”一样向支付页面注入指令、模拟点击、甚至自动填写验证信息从而在用户毫无察觉的情况下完成盗刷。这个内容适合所有对Web安全、前端安全、支付风控感兴趣的朋友无论是安全研究员、开发工程师还是风控策略的制定者。了解这种攻击的原理不仅能帮助我们更好地防御也能在设计支付流程时提前规避风险。接下来我将从攻击脚本的设计思路、核心技术点拆解、防御视角的实操分析以及我们该如何构建更安全的支付环境这几个方面进行一次深度的技术剖析。2. 攻击脚本的整体设计与核心思路拆解要理解这种攻击我们不能只停留在“它用了WebRTC”这个层面必须深入其设计逻辑。一个完整的“WebRTC型支付盗刷脚本”通常不是单一技术而是一个精巧组合的攻击链。2.1 攻击链全景与角色分工这类攻击通常涉及三个关键角色攻击者服务器、恶意着陆页和受害者环境。攻击链可以概括为诱导访问 - 建立隐蔽通道 - 实施远端操控。首先攻击者会通过短信、钓鱼邮件或社交工程等方式诱导受害者点击一个链接访问那个精心构造的恶意着陆页。这个页面看起来可能完全无害甚至是一个仿冒的正规网站登录页。它的核心任务有两个一是在受害者浏览器中悄无声息地运行恶意JavaScript脚本二是利用WebRTC尝试“穿透”受害者的本地网络。为什么选择WebRTC作为突破口传统的跨域请求受到同源策略的严格限制恶意网站很难直接与用户本地网络中的另一个标签页或应用比如正在进行的支付页面通信。而WebRTC的STUN/TURN/ICE协议簇在设计上就是为了帮助两个浏览器端点发现彼此并建立直接连接即使它们位于NAT或防火墙之后。攻击脚本正是滥用了这个“网络发现与穿透”能力。它通过恶意页面向外发起WebRTC连接尝试目标地址可能是预设的攻击者服务器用于中继控制指令更危险的是它可能尝试发现并连接本地网络中的其他设备。想象一下你一边用电脑浏览网页一边用手机进行支付操作两者在同一个Wi-Fi下恶意脚本就有可能尝试连接到你的手机。2.2 脚本的核心模块解析一个功能相对完整的攻击脚本通常会包含以下几个模块WebRTC信令与连接模块这是脚本的心脏。它负责使用RTCPeerConnectionAPI创建对等连接。脚本会生成SDP会话描述协议Offer并通过一个隐蔽的信令通道例如混在正常的图片请求或WebSocket连接中将其发送给攻击者控制的信令服务器。同时它也会监听来自信令服务器的Answer以完成连接建立。关键在于这个连接的数据通道RTCDataChannel被配置为传输控制指令而非音视频流。本地网络探测与横向移动模块脚本不会傻傻地只等待外连。为了增加成功率它通常会包含一个本地网络扫描组件。通过结合WebRTC的本地IP地址发现RTCPeerConnection.getStats或更早的window.RTCPeerConnection漏洞可以枚举本地网卡信息以及一些基于JavaScript的有限端口扫描技术如利用Image对象加载超时判断内网服务脚本会尝试绘制受害者本地网络拓扑寻找可能存在漏洞或开放服务的内网IP为后续的横向渗透做准备。支付页面指纹识别与自动化注入模块这是执行盗刷动作的“手”。脚本需要识别出当前浏览器中或者在同一本地网络环境下可访问的标签页中是否存在支付页面。它可能通过检查页面标题document.title、URL关键字如包含pay、checkout、alipay、wechat等、或特定的DOM元素如输入框的name属性包含cardNumber、cvv来进行指纹识别。一旦识别成功脚本便会通过已建立的WebRTC数据通道接收来自攻击者的指令。这些指令被解析后通过浏览器自动化技术如直接操作DOM、模拟键盘事件KeyboardEvent、鼠标事件MouseEvent注入到支付页面完成表单填写、勾选协议、点击支付按钮等一系列操作。隐蔽与对抗检测模块为了持久化和逃避检测脚本会采用多种混淆技术如代码压缩、变量名混淆、字符串加密来增加静态分析的难度。在运行时它会检测自己是否运行在开发者工具检查window.console或debugger语句、模拟用户环境如检测浏览器插件、屏幕分辨率、鼠标移动轨迹甚至在一些沙箱或分析环境中主动停止执行。通信数据也通常会进行加密混入正常的网络流量中。注意这里描述的是一个技术上的可能性模型用于理解攻击原理。在实际中实施此类攻击是严重的违法行为。本文的所有技术讨论仅出于安全研究与防御的目的。2.3 为什么这种攻击难以防范这种攻击模式之所以危险在于它巧妙地利用了多个“信任边界”的模糊地带浏览器对WebRTC的信任浏览器将WebRTC视为一项强大的标准功能默认启用并为它提供了强大的网络穿透能力。用户对“当前网页”的信任用户通常只警惕陌生的弹窗或下载但对于一个正在浏览的网页背后发生的复杂网络连接行为感知很弱。本地网络的“内网安全”假象许多用户认为家庭或公司内网是安全的忽略了从内部发起的横向威胁。支付流程的自动化测试漏洞一些支付页面的前端验证逻辑不够健壮过于依赖客户端逻辑容易被自动化脚本模拟和绕过。攻击脚本的设计思路正是系统性地串联这些弱点构建出一条从互联网到用户支付终端的隐蔽攻击路径。3. 核心技术点深度解析与实操要点理解了整体思路我们再来逐一拆解其中的关键技术环节。只有深入细节才能找到有效的防御点。3.1 WebRTC连接滥用从通信到控制的蜕变WebRTC建立连接的标准流程包括交换SDPOffer/Answer和收集ICE候选地址。在盗刷脚本中这个流程被恶意改造。恶意Offer的构造脚本在创建RTCPeerConnection时会有意配置iceServers。除了使用公共STUN服务器如stun:stun.l.google.com:19302来获取公网IP更关键的是它可能会尝试配置指向攻击者自建TURN服务器的地址。TURN服务器是一个中继当P2P直连失败时所有数据都会通过TURN服务器转发。攻击者自建TURN服务器就等于拥有了一个可控的数据中转站。脚本生成的SDP Offer中会包含这些服务器信息以及它希望建立的数据通道RTCDataChannel的配置。信令的隐蔽传输SDP Offer和Answer需要通过网络交换这个过程称为信令。攻击脚本不会使用明显的WebSocket或HTTP POST到一个可疑域名。相反它可能将信令数据编码后通过以下几种方式偷渡出去WebRTC Data Channel 打洞先尝试用另一个更简单的WebRTC连接与攻击者服务器建立数据通道然后用这个通道传输主要攻击连接的信令。套娃式的连接增加追踪难度。混入正常请求将信令数据分段作为参数附加到对第三方分析脚本如Google Analytics、字体库或常见CDN资源的请求URL中。这些请求通常不会被拦截。利用现有连接如果页面本身存在WebSocket连接例如在线聊天可能会尝试劫持或复用该连接传输信令数据。数据通道的利用一旦连接建立RTCDataChannel就成为了一条双向、低延迟的隐蔽隧道。攻击者通过这条隧道发送经过序列化如JSON和加密的指令包。指令可能包括{“cmd”: “find”, “selector”: “input[name’cardNumber’]”}- 查找卡号输入框。{“cmd”: “fill”, “selector”: “#cvv”, “value”: “123”}- 填写CVV码。{“cmd”: “click”, “selector”: “.submit-btn”}- 点击提交按钮。{“cmd”: “screenshot”}- 指令受害者浏览器对当前页面截图并通过通道回传通过html2canvas等库实现让攻击者能“看到”支付页面状态。3.2 浏览器内自动化与DOM操纵的细节收到指令后脚本需要在受害者浏览器上下文中执行自动化操作。这里不能使用常见的自动化测试工具如Selenium或Puppeteer因为这些需要独立的驱动程序。恶意脚本依赖的是纯前端JavaScript的能力。跨标签页/跨域操作的限制与绕过这是最大的技术难点。浏览器的同源策略严格禁止一个页面的脚本访问另一个不同源页面的DOM。攻击脚本通常采用以下两种思路同源内攻击如果支付页面和恶意页面是同一个域名例如攻击者成功克隆了一个山寨支付站点的子页面那么脚本可以直接操作。但这在针对大型支付平台时很难实现。诱导用户行为与事件模拟这是更常见的方式。脚本并不直接“访问”支付页面的DOM而是通过模拟全局事件来“影响”它。例如脚本可以监听支付页面是否被打开通过window.open或用户手动打开然后通过window.postMessageAPI向目标窗口发送消息。如果支付页面不慎监听了message事件并处理了内容就可能中招。更普遍的是攻击者依赖社会工程诱导用户先访问恶意页然后让用户自己切换到支付页进行操作。此时恶意页脚本仍在后台运行它可以通过轮询document.hasFocus()或监听visibilitychange事件来感知用户切换到了支付页然后通过WebRTC通道通知攻击者“目标已就位”攻击者再发送自动化指令。脚本在执行指令时模拟的是发生在当前恶意页面上的事件但通过技巧如先聚焦支付页面窗口window.focus()可以让事件被支付页面接收。精准的事件模拟光是触发事件不够还需要让事件看起来“真实”。一个简单的element.click()可能会被反欺诈系统检测到因为缺少伴随的鼠标移动mousemove事件。因此高级的脚本会模拟完整的事件序列// 模拟鼠标移动到元素上并点击 function simulateRealClick(element) { const rect element.getBoundingClientRect(); const x rect.left rect.width / 2; const y rect.top rect.height / 2; // 1. 鼠标移动 element.dispatchEvent(new MouseEvent(mousemove, { view: window, bubbles: true, cancelable: true, clientX: x, clientY: y })); // 2. 鼠标按下 element.dispatchEvent(new MouseEvent(mousedown, { view: window, bubbles: true, cancelable: true, button: 0 // 左键 })); // 3. 鼠标抬起点击完成 element.dispatchEvent(new MouseEvent(mouseup, { view: window, bubbles: true, cancelable: true, button: 0 })); // 4. 触发点击事件 element.dispatchEvent(new MouseEvent(click, { view: window, bubbles: true, cancelable: true, button: 0 })); }对于输入框则会模拟focus,keydown,keypress,input,keyup,change等一系列事件并在input事件中逐步设置value模仿真人打字速度。3.3 对抗检测与环境指纹收集为了存活更久脚本必须具备“反侦察”能力。环境检测开发者工具检测检查window.console是否被重写debugger关键字执行时间是否异常。自动化浏览器检测检查navigator.webdriver属性通常自动化浏览器会将其设为true检查浏览器插件列表是否异常真实用户通常有多个插件检查屏幕分辨率、颜色深度、可用字体等是否与常见自动化环境如Headless Chrome一致。行为检测记录鼠标移动轨迹检查其是否符合人类移动的贝塞尔曲线特征而非机械的直线移动。检查点击位置是否总是元素的精确中心点。代码混淆与动态加载脚本主体可能经过UglifyJS、Terser等工具压缩混淆关键字符串和函数名被替换为无意义的字符。更高级的会采用“代码碎片化”技术将功能拆分成多个小片段通过动态创建script标签或eval函数按需加载和执行增加静态分析的难度。核心的WebRTC连接逻辑甚至可能被加密只在运行时通过一个简单的解密函数还原。通信隐匿WebRTC数据通道本身使用DTLS/SRTP加密这提供了基础的传输安全。攻击者还会在应用层对指令数据进行二次加密。通信频率也会模仿正常用户行为比如在用户看似“阅读页面”的等待期进行低频心跳保活在检测到支付页面激活时才进行高频指令传输。4. 防御视角检测、缓解与根治方案作为防御方我们需要从多个层面构建防线让这类攻击脚本失效或难以生效。4.1 前端层面的实时检测与对抗支付页面自身的前端代码是防御的第一道关口。WebRTC连接尝试监控可以在页面中嵌入监控脚本监听RTCPeerConnection的创建。虽然恶意脚本可能在自己的上下文中创建连接但我们可以监控全局// 拦截并监控 RTCPeerConnection 构造函数 const OriginalRTCPeerConnection window.RTCPeerConnection; window.RTCPeerConnection function(configuration) { console.warn(RTCPeerConnection created with config:, configuration); // 分析 configuration.iceServers检查是否有可疑的TURN服务器地址 // 可以上报到风控服务器进行分析 return new OriginalRTCPeerConnection(configuration); }; window.RTCPeerConnection.prototype OriginalRTCPeerConnection.prototype;同时监控RTCDataChannel的创建和消息发送。任何非音视频用途的WebRTC连接尝试都应被视为高度可疑。用户行为生物特征验证引入更精细的行为分析。不仅仅检测“是否在操作”而是分析“如何操作”。鼠标动力学记录鼠标移动速度、加速度、轨迹弯曲度。自动化脚本的移动往往是线性、匀速的。击键动力学记录按键之间的时间间隔击键延迟和按住一个键的时间击键时长。每个人的打字节奏都是独特的自动化脚本的输入节奏过于均匀完美。触摸行为在移动端分析触摸手势的力度、面积、滑动轨迹等。 这些生物特征数据可以在前端初步计算形成特征向量然后发送到后端与当前用户的历史行为模型进行比对。偏离度过大则触发二次验证。操作上下文与环境一致性检查事件序列完整性检查关键操作如点击支付按钮前是否经历了完整的mousemove-mouseover-mousedown-mouseup-click事件序列。缺少前置事件可能是程序触发。时间戳合理性检查表单填写时间。一个复杂的表单在毫秒级内被填完显然不正常。焦点与可视状态检查触发支付操作时支付页面标签页是否处于前台document.hasFocus()和可见状态document.visibilityState。如果页面一直处于后台却被操作极其可疑。4.2 后端风控系统的联动防御前端检测可以增强但最终决策和防御核心应放在后端。设备指纹与关系图谱后端需要构建强大的设备指纹系统采集浏览器Canvas指纹、WebGL指纹、音频指纹、已安装字体列表、屏幕属性等硬软件信息生成一个高稳定性的设备ID。当发生支付行为时检查本次支付的设备指纹与账户常用设备指纹是否一致。同时建立设备关系图谱如果一个设备ID在短时间内关联了多个不同账户的支付行为尤其是失败或盗刷行为则该设备应被标记为高风险。网络与位置异常检测IP信誉库对接第三方IP信誉服务或自建库检查请求IP是否来自数据中心、代理服务器、或已知的恶意IP段。地理速度异常如果用户上一次登录在A地一小时后支付请求从物理上不可能到达的B地发出则触发警报。结合WebRTC泄露的本地IP如果获取到可以更精确地定位用户大致内网环境与常用环境进行比对。WebRTC泄露IP比对虽然现代浏览器已限制通过JavaScript直接获取本地IP但仍可通过某些方式间接探测。风控后端可以主动向客户端发送一个需要WebRTC交互的挑战例如一个简单的视频验证在交互过程中分析SDP信息获取客户端的真实公网IP和可能的局域网IP与HTTP请求头中的X-Forwarded-For等IP进行比对不一致可能意味着请求经过了代理或劫持。交易模式识别与机器学习模型这是风控的大脑。需要训练模型识别盗刷交易的模式特征交易频率与金额短时间内高频、尝试性小额支付或突然进行远超历史记录的大额支付。商品特征虚拟物品、充值卡、数字货币等易于变现的商品是盗刷者的最爱。操作流程异常跳过浏览、比价、加入购物车等正常流程直接访问支付链接表单填写速度极快且无修改支付成功后立即发起退款或转账请求。结合前端上报数据将前端检测到的“自动化风险评分”、“行为生物特征偏离度”、“WebRTC异常连接记录”等作为特征输入模型进行综合决策。4.3 基础设施与开发流程的加固防御需要深入到架构和流程中。内容安全策略CSP的严格配置一个强化的CSP头部能极大限制恶意脚本的能力。对于支付相关页面应配置最严格的策略Content-Security-Policy: default-src self; connect-src self api.trusted-payment-gateway.com; script-src self nonce-{随机值}; object-src none; frame-src none;connect-src限制了可连接的源应禁止所有不必要的域名特别是要评估是否真的需要允许*所有或wss:WebSocket和stun:/turn:WebRTC。对于绝大多数支付页面完全可以禁止WebRTC相关的连接。使用nonce或hash来允许内联脚本代替不安全的unsafe-inline。禁止object-src和frame-src或严格限制以防止插件和iframe攻击。服务器端渲染SSR与关键逻辑后置将核心的业务逻辑尤其是支付状态流转、优惠券核销、库存扣减等完全放在后端。前端只负责展示和收集数据。任何重要的操作如提交支付必须由前端发送请求到后端后端完成所有验证金额、商品、用户状态、风控检查后再调用支付网关。避免在前端JavaScript中直接调用支付接口或处理核心逻辑。定期安全审计与渗透测试将“滥用WebRTC进行跨页面操作”纳入常规的渗透测试用例中。安全团队应定期尝试使用类似技术模拟攻击检查现有防护措施的有效性。同时对第三方依赖JavaScript库、SDK进行严格的安全审查确保没有引入恶意代码或存在被利用的漏洞。用户教育与终端防护提示用户在支付页面可以明确提示用户“请确保在支付过程中不要切换标签页或打开其他不明链接”。推广安全插件鼓励用户使用具有脚本管理、隐私保护功能的浏览器插件如NoScript、uBlock Origin等它们可以默认阻止WebRTC等敏感API或需要用户手动授权。浏览器设置对于高安全要求的用户可以指导他们如何在浏览器设置中禁用WebRTC例如在Chrome中通过chrome://flags/#disable-webrtc或使用插件。5. 常见问题排查与实战调试技巧在研究或防御这类威胁时我们常常需要进行分析和调试。以下是一些实用的技巧和常见问题的排查思路。5.1 如何识别页面中是否存在恶意WebRTC脚本手动检查开发者工具网络面板刷新页面在Network面板中过滤webrtc、stun、turn、ice等关键词。查看是否有向陌生域名或IP的STUN/TURN服务器发起的请求。这些请求可能使用TURNTCP或UDP 3478端口或STUNUDP 3478端口协议。发起程序追踪在Network中找到可疑的WebRTC相关请求点击其“Initiator”标签可以回溯是哪个脚本文件发起了这个连接。仔细审查该脚本文件的内容。控制台监控在Console中执行以下代码监听WebRTC相关事件const origCreate RTCPeerConnection.prototype.createOffer; RTCPeerConnection.prototype.createOffer function(...args) { console.trace(createOffer called, this); return origCreate.apply(this, args); }; // 类似地可以重写 createAnswer, addIceCandidate 等检查ICE服务器配置在可疑脚本中搜索iceServers、urls、stun:、turn:等关键字。合法的应用通常会使用公开的STUN服务器如Google、Twilio的或自己业务相关的TURN服务器。陌生的、尤其是IP地址形式的TURN服务器非常可疑。自动化工具辅助使用浏览器扩展如WebRTC Leak Prevent、uBlock Origin高级模式来管理和阻止WebRTC连接。使用开源工具如webrtc-internalsChrome内置访问chrome://webrtc-internals可以详细查看当前页面的所有WebRTC连接状态、统计信息和日志对于分析非常有用。5.2 调试时模拟攻击环境需要注意什么法律与道德边界绝对只能在你自己完全可控的环境中进行测试例如本地虚拟机、自己的测试服务器、或获得明确授权的测试目标。未经授权对他人的系统进行任何形式的WebRTC探测或自动化操作都是非法的。环境隔离使用虚拟机或独立的浏览器用户配置文件进行测试。避免使用日常工作的主浏览器和环境防止测试脚本意外影响到你的真实账户或数据。使用无头浏览器与自动化工具为了理解攻击脚本的行为你可以使用Puppeteer或Selenium编写测试脚本模拟恶意页面的行为。这能帮助你验证WebRTC连接是否能成功建立。观察脚本在不同反自动化检测策略下的行为。记录网络请求和Console输出分析其攻击逻辑。// Puppeteer 示例监听WebRTC连接 const browser await puppeteer.launch(); const page await browser.newPage(); await page.goto(http://your-test-page); // 覆盖RTCPeerConnection以进行监听 await page.evaluateOnNewDocument(() { window.peerConnections []; const OrigPeerConnection window.RTCPeerConnection; window.RTCPeerConnection function(...args) { const pc new OrigPeerConnection(...args); window.peerConnections.push(pc); console.log(New RTCPeerConnection created:, args); return pc; }; });5.3 防御措施上线后可能遇到的问题CSP策略过于严格导致功能异常这是最常见的问题。在部署严格的CSP后务必进行全面的功能回归测试。重点关注第三方支付网关、登录SDK、客服聊天插件、数据统计脚本是否因为connect-src或script-src限制而失效。网站自身的内联事件处理器如onclick”…”或动态创建的脚本是否因为缺少nonce而无法执行。使用report-uri或report-to指令收集CSP违规报告持续监控和调整策略。行为验证导致的误拦截生物特征和行为分析模型在初期可能会有较高的误报率。例如用户使用新的输入设备如外接键盘、网络延迟高导致操作卡顿、或者用户本身就是“手速很快”的人都可能被模型误判。解决方案建立多级验证机制。对于低风险异常可以仅记录日志或进行轻度挑战如拖动滑块。对于中高风险触发短信/邮箱验证码。对于高风险直接要求人工客服介入。同时模型需要持续训练用真实的误报和漏报样本进行迭代优化。WebRTC禁用对合法功能的影响如果你的业务本身依赖WebRTC如在线客服视频、在线教育、游戏那么完全禁用WebRTC是不可行的。解决方案实施白名单机制。只有来自特定域名你的业务域名的页面并且在用户明确授权例如点击“开始视频通话”按钮后才允许创建WebRTC连接。可以通过前置的权限请求页面来实现。对抗升级攻击者也在不断进化。当基础的WebRTC直接连接被阻断后他们可能会转向更复杂的技术例如利用WebSocket进行中继恶意脚本通过WebSocket与攻击服务器保持长连接服务器将控制指令通过WebSocket下发脚本在本地执行后再将结果回传。这绕过了对WebRTC的直接检测。使用Service Worker作为持久化后台脚本即使关闭恶意标签页Service Worker仍可在后台运行维持通信并等待支付页面出现。利用浏览器0day漏洞或已安装恶意扩展这属于更高阶的攻击。 因此防御不能是一劳永逸的需要建立持续的安全监控、威胁情报收集和快速响应机制。真正的安全是一个动态的过程而非静态的产品。面对“WebRTC型支付盗刷脚本”这类融合了多种前端技术的攻击我们需要从前端代码加固、后端风控联动、基础设施策略、到用户安全意识教育构建一个立体的、深度的防御体系。每一次对攻击技术的深入分析都是为了能让我们的防线更加稳固。在实际工作中我习惯于将任何新上线的支付或敏感操作功能都放在一个假想的“恶意脚本环境”中去思考如果有一个脚本正在试图自动化这个流程我的设计在哪里能打断它这种思维方式往往能发现那些在正常测试中容易被忽略的漏洞。