DOM型XSS漏洞原理与前端修复方案

当你在浏览器控制台看到一条XSS告警，或者某个输入框突然弹出一个陌生对话框，你很可能遇到了DOM型XSS漏洞。与反射型、存储型XSS不同，DOM型XSS不依赖服务器端响应，而是完全在前端JavaScript执行过程中触发——它源于代码对DOM操作的不当处理，使得攻击者能通过操纵URL或页面状态，注入并执行恶意脚本。这类漏洞隐蔽性强，常规的WAF（Web应用防火墙）往往无法拦截，因为它根本不经过服务器。本文将从实际案例出发，分析DOM型XSS的触发原理，并给出可落地的前端修复方案。

一个典型的DOM型XSS触发场景

假设你的页面有一个搜索功能，代码如下：

// 从URL获取查询参数
const search = new URLSearchParams(window.location.search).get('q');
// 直接将参数插入DOM
document.getElementById('result').innerHTML = '你搜索的是：' + search;

当攻击者构造链接 https://example.com/?q=<img src=x onerror=alert(1)> 并诱导用户点击时，search 的值被当作HTML插入，onerror 事件触发，恶意脚本执行。这里没有任何服务器参与，所有操作都在浏览器端完成。

这类漏洞的根源在于：前端代码将不可信数据直接传入 innerHTML 或 document.write 等危险方法。修复思路也很明确：要么对数据进行转义，要么使用安全API，要么从源头限制输入。

DOM型XSS的常见攻击面

除了URL参数，以下位置也常被利用：

location.hash：片段标识符不发送到服务器，但可被JavaScript读取。
window.name：跨窗口传递数据时，可能被恶意页面控制。
postMessage：跨文档消息通信，若未校验来源和内容，可能导致注入。
localStorage/sessionStorage：存储的数据若被污染，也可能成为注入源。

攻击者通常利用这些入口，将恶意代码嵌入URL或页面状态，诱导用户点击。由于攻击载荷不经过服务器，传统的服务端过滤和WAF无法识别。

前端修复方案：从源头阻断

修复DOM型XSS的核心是“不信任任何外部数据”，具体操作如下：

1. 使用安全DOM API

用 textContent 替代 innerHTML，用 createElement 和 appendChild 构建DOM结构，避免直接插入HTML字符串。例如：

const result = document.getElementById('result');
result.textContent = '你搜索的是：' + search; // 安全，不会解析HTML

如果必须使用 innerHTML，务必将用户数据转义：

function escapeHtml(str) {
  return str.replace(/[&"']/g, function(m) {
    return {'&':'&','':'>','"':'"',"'":'''}[m];
  });
}
result.innerHTML = '你搜索的是：' + escapeHtml(search);

2. 验证和过滤输入

对URL参数、hash等输入进行白名单校验。比如，搜索参数只允许字母、数字和空格：

const safeSearch = search.replace(/[^ws]/g, '');

对于复杂场景，可使用DOMPurify等库净化HTML。但注意，输入过滤不能作为唯一防线，因为DOM操作可能发生在多个环节。

3. 使用CSP（内容安全策略）

CSP可以限制脚本执行来源，即使注入成功，也无法加载外部恶意脚本。设置响应头：

Content-Security-Policy: script-src 'self'

这能有效缓解XSS影响，但需要注意内联脚本和eval的禁用，可能影响现有功能。CSP是纵深防御的重要一环，建议与前端修复结合使用。更详细的配置可参考Web安全响应头配置指南。

4. 避免使用危险函数

审查代码，避免使用 eval()、new Function()、setTimeout('string') 等动态执行字符串的API。如果必须使用，确保传入的是可信数据。

借助CDN和边缘计算增强防护

虽然DOM型XSS不经过服务器，但CDN和边缘计算可以在传输层提供额外保护。例如，Cloudflare的CDN可以缓存静态资源，加速内容分发，同时其DDoS防护能抵御大规模攻击，间接降低风险。更重要的是，Cloudflare Workers允许在边缘运行JavaScript，你可以编写代码检查请求URL，拦截明显的攻击载荷，或者修改响应头添加CSP。

例如，一个Worker可以检查查询参数并剔除危险字符：

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request));
});
async function handleRequest(request) {
  const url = new URL(request.url);
  // 清理查询参数
  url.searchParams.forEach((value, key) => {
    url.searchParams.set(key, value.replace(/[&"']/g, ''));
  });
  const newRequest = new Request(url, request);
  const response = await fetch(newRequest);
  // 添加CSP头
  const newHeaders = new Headers(response.headers);
  newHeaders.set('Content-Security-Policy', "script-src 'self'");
  return new Response(response.body, { status: response.status, headers: newHeaders });
}

虽然这不能根治DOM型XSS，但能减少攻击面，并提供统一的安全策略部署。

常见误区与失败条件

误区一：只做输入过滤。输入过滤可能被绕过，且DOM操作可能来自多个数据源。
误区二：依赖服务端转义。DOM型XSS不经过服务端，服务端转义无效。
误区三：使用innerHTML但手动转义不完整。漏掉某些字符（如反引号）可能导致绕过。
失败条件：如果应用依赖大量内联脚本，启用CSP script-src 'self' 可能导致功能瘫痪，需谨慎调整策略。

总结

DOM型XSS漏洞源于前端对不可信数据的信任，修复需要从代码层面入手：使用安全API、验证输入、配置CSP。同时，CDN和边缘计算可以作为辅助手段，提供请求过滤和响应头设置。记住，安全是一个持续过程，定期审查代码、更新依赖、关注新攻击向量，才能有效抵御威胁。

参考资料

延伸阅读