DOM-Based XSS：客户端XSS攻击原理、实战与防御策略

1. 项目概述DOM-Based XSS一个被低估的客户端“幽灵”在Web安全领域跨站脚本攻击XSS早已是臭名昭著的老对手。无论是反射型还是存储型其攻击路径都离不开“服务器响应”这个环节这也使得传统的防御手段如Web应用防火墙WAF和服务器端输入过滤有了明确的防御阵地。然而今天我们要深入探讨的DOM-Based XSS却像是一个游荡在客户端浏览器里的“幽灵”。它完全在用户的浏览器中发生恶意脚本的注入和执行服务器端可能毫不知情传统的安全设备甚至“看”不到攻击流量。对于前端开发者、安全工程师乃至普通用户而言理解这个“幽灵”的运行机制是构建真正纵深防御体系的关键一环。简单来说DOM-Based XSS是一种攻击者通过操纵页面的文档对象模型DOM来注入并执行恶意脚本的攻击方式其特殊性在于整个攻击的“罪魁祸首”是前端JavaScript代码对不可信数据源的不安全处理。2. DOM-Based XSS的核心原理与攻击模型拆解要理解DOM-Based XSS我们必须先抛开“服务器-客户端”的传统攻击视角将目光聚焦于浏览器内部。2.1 DOM动态网页的基石与潜在的风险接口DOM不是一个编程语言而是一个由W3C定义的、独立于平台和语言的接口。它允许程序和脚本主要是JavaScript动态地访问和更新文档的内容、结构及样式。当浏览器加载一个HTML页面时它会解析HTML和CSS并在内存中构建一棵DOM树。这棵树上的每一个节点都对应着页面中的一个元素如div、input。JavaScript的强大之处在于它可以通过DOM API如document.getElementById、innerHTML、location.hash来读取和修改这棵树。正是这种“动态性”带来了风险如果修改DOM的数据来源不可信且修改方式不安全攻击者就能“教唆”JavaScript代码在DOM中“写入”恶意脚本。2.2 攻击链条从数据源到执行点的完整路径一次典型的DOM-Based XSS攻击其生命周期完全在客户端闭环可以拆解为以下清晰链条不可信数据源注入攻击者找到一个方式将恶意数据“放入”一个能被页面JavaScript访问的数据源中。这个数据源并非来自服务器响应体而是来自客户端环境本身。最常见的源头包括window.location对象特别是location.hashURL中#后面的部分、location.searchURL中?后面的查询参数。攻击者可以构造一个恶意链接如https://vulnerable-site.com/page#scriptalert(1)/script。document.referrer当前页面的来源URL。如果页面逻辑会根据referrer来动态生成内容攻击者可以诱导用户从一个恶意网站跳转过来。document.cookie尽管有HttpOnly保护但某些脚本可能会错误地读取和输出Cookie内容。window.name这个属性可以在页面跳转或iframe嵌套时传递数据且生命周期较长。浏览器存储如localStorage、sessionStorage如果存储的数据被未经验证地取出并使用。来自其他窗口/iframe的消息通过postMessageAPI传递的数据。不安全的DOM操作Sink页面中存在一段JavaScript代码它从上述某个不可信数据源中读取了数据然后通过一个“危险”的DOM操作方法将这些数据当成了HTML或JavaScript代码来执行。这些危险的方法被称为“Sink”接收器。高危的Sink包括element.innerHTML userDataelement.outerHTML userDatadocument.write(userData)document.writeln(userData)eval(userData)setTimeout(userData, time)setInterval(userData, time)location.href userData(如果userData以javascript:开头)某些HTML属性赋值如element.setAttribute(onclick, userData)脚本执行与攻击达成当不可信数据通过Sink被写入DOM时如果其中包含的脚本标签script或事件处理器如onload、onerror被浏览器解析并执行攻击便告成功。此时恶意脚本拥有当前页面的同源权限可以窃取Cookie未设置HttpOnly的、发起恶意请求、篡改页面内容、进行键盘记录等。注意这里有一个关键区别。在反射型XSS中恶意脚本是服务器“反射”回HTML响应中的。在DOM-Based XSS中服务器返回的可能是完全干净、正常的HTML。是客户端JS“主动地”从URL里取出恶意代码并塞进了DOM。2.3 与反射型、存储型XSS的本质区别为了更深刻理解我们用一个表格来对比特征反射型XSS存储型XSSDOM-Based XSS恶意代码存储位置在URL中由受害者请求携带服务器数据库/文件系统客户端URL片段、浏览器存储等触发方式用户点击特制链接用户访问包含恶意代码的页面用户访问特制链接或页面执行特定JS逻辑服务器角色解析请求参数将其嵌入响应HTML存储并提供恶意代码可能完全不参与返回静态HTML检测难度相对容易WAF可检测请求与响应相对容易扫描器可检测存储点极难攻击流量不经过服务器WAF无效修复重点服务器端对输入输出编码/过滤服务器端对存储和输出编码/过滤客户端JavaScript安全编码这个对比清晰地表明DOM-Based XSS的防御阵地发生了根本性转移从前端开发阶段就必须介入。3. 实战演练解剖一个经典的DOM-Based XSS漏洞理论说得再多不如亲手“制造”并修复一个漏洞来得直观。我们假设一个常见的场景一个单页面应用SPA有一个“欢迎消息”功能消息内容从URL的hash中读取并动态显示在页面上。3.1 漏洞代码示例!DOCTYPE html html head title欢迎页面 - 漏洞版/title /head body h1网站首页/h1 div idwelcome-message !-- 消息将在这里动态显示 -- /div script // 漏洞点从 location.hash 获取数据并直接使用 innerHTML 插入 function displayWelcomeMessage() { const message window.location.hash.substring(1); // 去掉开头的 # const welcomeDiv document.getElementById(welcome-message); if (message) { // 高危操作直接将未经验证的用户输入作为HTML解析 welcomeDiv.innerHTML 欢迎您 message ; } else { welcomeDiv.innerHTML 欢迎您访客; } } // 页面加载时和hash变化时都更新消息 window.onload displayWelcomeMessage; window.onhashchange displayWelcomeMessage; /script /body /html这段代码的意图是好的如果用户访问https://example.com/#张三页面上会显示“欢迎您张三”。它甚至考虑了单页面应用的路由特性监听了hashchange事件。3.2 攻击者如何利用攻击者会这样思考寻找Sink代码中使用了innerHTML来设置div的内容。寻找数据源innerHTML的值由window.location.hash拼接而成。构造Payload攻击者需要构造一个hash使得拼接后的字符串在作为HTML解析时能执行脚本。一个最简单的攻击Payload是#img srcx onerroralert(document.cookie)用户访问的完整URL被攻击者构造为https://vulnerable-site.com/#img srcx onerroralert(document.cookie)window.location.hash.substring(1)得到img srcx onerroralert(document.cookie)welcomeDiv.innerHTML 欢迎您 img srcx onerroralert(document.cookie) ;浏览器解析这段HTML创建了一个img元素其srcx显然是一个无效地址。图片加载失败触发onerror事件处理器执行其中的JavaScript代码alert(document.cookie)。此时如果该站点的Cookie未设置HttpOnly就会被弹窗显示出来攻击者可通过更复杂的脚本将其发送到自己的服务器。实操心得innerHTML不仅会执行script标签任何能触发脚本执行的HTML属性都是突破口如onload、onerror、onmouseover等事件处理器以及a hrefjavascript:...、iframe srcjavascript:...等。攻击Payload千变万化。3.3 漏洞修复正确的安全编码实践修复的核心原则是将数据与代码分离。对于需要动态显示文本内容的地方绝不应该使用innerHTML而应使用只处理文本的API。修复后的代码script function displayWelcomeMessage() { const message window.location.hash.substring(1); const welcomeDiv document.getElementById(welcome-message); if (message) { // 修复使用 textContent 或 innerText welcomeDiv.textContent 欢迎您 message ; } else { welcomeDiv.textContent 欢迎您访客; } } window.onload displayWelcomeMessage; window.onhashchange displayWelcomeMessage; /script使用textContent属性无论message变量里包含什么都会被当作纯文本字符串直接显示在页面上浏览器不会对其进行HTML解析。img srcx onerroralert(1)会原封不动地显示为字符而不是一个图片元素。重要提示如果业务场景必须要动态生成HTML结构例如渲染一段来自后端的富文本那么绝不能直接拼接字符串后使用innerHTML。必须使用经过严格验证和净化的方法。这时应该使用一个成熟的、专门用于防御XSS的库例如DOMPurify。它的作用是像过滤器一样只允许安全的HTML标签和属性通过。// 使用DOMPurify库的示例 import DOMPurify from dompurify; const dirtyInput window.location.hash.substring(1); const cleanHTML DOMPurify.sanitize(dirtyInput); // 净化后的HTML welcomeDiv.innerHTML 欢迎您 cleanHTML ;4. 深入挖掘其他常见危险模式与高级利用技巧除了innerHTMLlocation.hash这个经典组合DOM-Based XSS还有许多其他“变种”。4.1 基于eval()或setTimeout/setInterval的动态代码执行这是另一种高危模式。eval()函数会将其字符串参数当作JavaScript代码来执行。// 危险代码从URL参数中获取要执行的函数名 const functionName new URLSearchParams(window.location.search).get(callback); eval(functionName ()); // 如果callback是alert(1)//则执行alert(1) // 同样危险的变体 setTimeout(location.search.split()[1], 100); setInterval(console.log(${userInput}), 1000);修复方案绝对避免使用eval()。如果需要动态执行代码应使用安全的替代方案如使用对象映射对象查找。const allowedCallbacks { success: handleSuccess, error: handleError }; const functionName new URLSearchParams(window.location.search).get(callback); const funcToCall allowedCallbacks[functionName]; if (funcToCall typeof funcToCall function) { funcToCall(); // 安全只执行白名单内的函数 }4.2 jQuery中的安全隐患在老式或使用不当的jQuery项目中以下方法同样危险$(#el).html(userInput)$(div).append(userInput)$(userInput)// 直接解析字符串为DOMjQuery的.html()方法和$()构造函数在遇到以开头的字符串时会尝试解析为HTML。修复方法与原生JS一致显示文本用.text()净化HTML用专门的库。4.3 利用 AngularJS / Vue.js 等框架的客户端模板注入早期的AngularJSv1.x有一个特性模板中的{{ expression }}会被动态求值。如果攻击者能够控制这个表达式就可能造成客户端模板注入本质上也是一种DOM-Based XSS。!-- 假设 userInput 可控 -- div ng-app p{{ userInput }}/p /div script // 如果 userInput 是 ‘1 alert(1)’在旧版AngularJS中可能触发弹窗 /script修复方案对于现代前端框架React, Vue 3, Angular 2框架本身已经提供了基础的上下文输出编码。例如Vue的{{ }}和 React 的{}默认都会对动态内容进行HTML转义。关键在于不要使用v-html(Vue) 或dangerouslySetInnerHTML(React) 这类“危险”的API去渲染不可信数据。如果必须用必须配合严格的净化。5. 系统性的防御策略与最佳实践防御DOM-Based XSS不能只靠一两个补丁而需要一套贯穿开发流程的体系。5.1 开发阶段安全编码规范建立数据源清单在项目安全评审中明确所有可能被攻击者控制的客户端数据源Source。制作一个清单location(hash, search, pathname),document.referrer,window.name,localStorage,postMessage数据等。识别并规避危险Sink在代码审查和静态扫描中重点检查所有使用innerHTML、outerHTML、document.write、eval、setTimeout(string)、location.assign(javascript:...)的地方。建立ESLint规则禁止或警告使用这些API。强制使用安全API文本内容无条件使用textContent或innerText。属性值使用setAttribute()或直接通过属性名el.value设置而不是拼接字符串后赋值给innerHTML。URL处理在设置a.href、img.src、iframe.src等属性时必须验证协议。使用new URL()API进行解析和校验确保不是javascript:协议。实施严格的输入验证与上下文输出编码验证对于从任何Source获取的数据根据预期用途进行严格验证如长度、格式、字符集。例如如果期望是用户名就只允许字母数字和少量符号。编码编码不是简单的过滤script。必须根据数据将要放置的上下文Context进行编码HTML上下文使用lt;,gt;,amp;,quot;,#x27;等转义。HTML属性上下文同上并确保属性值用引号包裹。JavaScript上下文使用\uXXXX形式的Unicode转义。URL上下文使用encodeURIComponent()。建议使用成熟的编码库如he来处理避免自己写容易出错的转义函数。5.2 部署与运行时增加攻击难度与成本内容安全策略CSP这是防御包括DOM-XSS在内的多种客户端攻击的终极利器。CSP通过HTTP响应头告诉浏览器哪些外部资源可以被加载和执行。Content-Security-Policy: default-src self; script-src self https://trusted.cdn.com; object-src none;script-src self表示只允许执行来自当前域名下的脚本。即使攻击者成功注入了scriptalert(1)/script浏览器也会因为CSP的限制而拒绝执行它。可以禁止内联脚本 (‘unsafe-inline’)这能有效阻止大部分基于事件处理器如onerror的XSS。但这也意味着你所有的JS必须放在外部文件里。注意CSP的配置需要非常小心错误的配置可能导致网站功能损坏。建议从Content-Security-Policy-Report-Only头开始只报告不拦截观察无误后再强制执行。设置安全的Cookie属性为会话Cookie设置HttpOnly和Secure属性。HttpOnly使JavaScript无法通过document.cookie读取Cookie即使发生XSS攻击者也难以直接窃取会话。Secure要求Cookie只能通过HTTPS传输。5.3 测试与监控主动发现漏洞自动化动态扫描DAST使用OWASP ZAP、Burp Suite等工具对Web应用进行自动化扫描。这些工具会尝试构造各种XSS Payload并观察响应。但对于纯客户端的DOM-XSS传统扫描器可能失效或需要特殊配置如启用浏览器驱动。手动渗透测试安全工程师通过浏览器开发者工具手动追踪数据流。方法是在潜在的数据源如URL参数处输入一个唯一标识符如test123然后在所有Sink如innerHTML赋值处设置断点或搜索页面源码看这个标识符是否会出现在危险的上下文中。代码审计与静态分析SAST使用SonarQube、CodeQL等工具对源代码进行扫描自动识别“Source-to-Sink”的数据流发现潜在的不安全模式。漏洞赏金计划邀请外部安全研究人员帮助发现漏洞。6. 常见问题排查与疑难场景解析在实际开发和防御中你可能会遇到一些令人困惑的场景。6.1 为什么我的WAF没报警但漏洞确实存在这是DOM-Based XSS最典型的特点。WAF通常部署在服务器前端检查的是HTTP请求和响应。在纯DOM-XSS攻击中请求攻击者发送的恶意Payload如在location.hash中不会作为请求体的一部分发送到服务器。#后面的部分hash是浏览器客户端使用的服务器根本收不到。响应服务器返回的HTML是干净、无恶意代码的。 因此WAF“看”不到攻击流量自然无法报警。防御重心必须前移到客户端代码安全。6.2 使用了Vue/React等现代框架是不是就高枕无忧了绝对不是。现代框架提供了默认的HTML转义极大地降低了风险但并非银弹。框架的“逃生舱”Vue的v-html指令、React的dangerouslySetInnerHTML属性就是为了绕过默认转义而设计的。一旦你使用了它们去渲染用户输入所有的安全风险就又回来了。危险的第三方库你引入的某个UI组件库其内部可能使用了innerHTML且未做净化。服务端渲染SSR在SSR场景下如果服务端拼接字符串生成HTML时未转义产生的将是存储型或反射型XSS而不是DOM-Based。但风险同样存在。URL和样式注入即使用{{ }}安全地输出了文本但如果你把用户输入直接用在:href或:style绑定里仍然可能导致javascript:URL注入或CSS注入虽然危害通常小于脚本执行。最佳实践即使使用框架也要遵循“永远不信任用户输入”的原则对用于“逃生舱”或属性绑定的数据进行严格的验证或净化。6.3 如何排查一个疑似DOM-XSS的漏洞报告收到一个形如https://your-site.com/#script...的漏洞报告时按以下步骤排查确认触发点在浏览器中打开该URL打开开发者工具F12。搜索源代码在“Elements”面板使用CtrlF搜索攻击Payload中的特征字符串如alert、onerror等。如果能在渲染后的DOM树中找到它说明它被当作HTML解析了。追踪数据流在“Sources”面板在所有JS文件中对location.hash、location.search、document.URL等关键词进行全局搜索。找到读取这些值的代码。查找Sink从读取数据源的代码出发向下追踪看这个值最终被传递到了哪里。是否传给了innerHTML、document.write、eval或类似函数验证修复修改代码使用textContent或净化库后重复步骤1-2确认恶意代码不再被解析执行。6.4 关于URL解析的安全陷阱JavaScript:协议是一个常见的陷阱。考虑以下代码const userInput javascript:alert(1); document.getElementById(myLink).href userInput; // 极度危险用户点击这个链接就会执行脚本。修复方法是在设置href等属性前必须验证协议function sanitizeUrl(url) { try { const parsed new URL(url, window.location.href); // 以当前页面为基准进行解析 if (![http:, https:, mailto:, tel:].includes(parsed.protocol)) { return about:blank; // 非安全协议返回一个无害的空页面 } return url; } catch { return about:blank; // 非法URL } } document.getElementById(myLink).href sanitizeUrl(userInput);DOM-Based XSS就像潜伏在客户端阴影中的刺客它绕过了传统的服务器端防线。对抗它需要开发者从根本上转变思维将“客户端数据同样不可信”作为安全编码的第一信条。从识别危险的Source和Sink到强制使用安全的API再到部署CSP这样的运行时防护这是一个需要开发、安全、运维共同参与的持续过程。每一次对innerHTML的审慎使用每一次对location.hash的严格校验都是在为你的应用构建一道坚固的客户端盾牌。