静态资源版本号防缓存XSS

静态资源版本号机制本是前端工程化中解决缓存更新的银弹，但在安全领域，它正在演变为一种隐蔽的持久型XSS攻击载体。攻击者通过污染版本号参数，将恶意脚本固化在浏览器缓存中，即便服务器修复了漏洞，只要用户不清除缓存，攻击依然会持续生效。这种攻击手法的精妙之处在于，它不依赖服务器存储恶意代码，而是利用浏览器强缓存策略，让恶意版本资源长期驻留。

现代前端项目中，静态资源的URL通常携带版本号或哈希值，例如 script.js?v=1.2.3 或 style.abc123.css。浏览器根据完整URL建立缓存标识，当版本号变化时触发资源更新。问题出在部分应用将版本号通过URL参数或路径片段动态拼接，且未对输入做充分过滤。攻击者构造如下请求：

https://example.com/static/app.js?v=1.0.0">

如果后端或前端将这个URL原样输出到页面中，引号闭合后注入的script标签就会被浏览器解析执行。更隐蔽的情况是，攻击者将恶意版本号通过分享链接传播，用户点击后触发缓存投毒。浏览器会将带有恶意版本号的资源缓存下来，后续正常访问时，如果缓存匹配逻辑存在缺陷，就可能加载被污染的缓存副本。

理解这个攻击的关键在于浏览器缓存策略。当静态资源设置了强缓存头，如 Cache-Control: max-age=31536000，浏览器在一年内都不会向服务器发起请求验证资源新鲜度。攻击者只需诱导用户访问一次携带恶意版本号的页面，该版本资源就会被缓存。即便网站管理员发现并修复了XSS漏洞，已缓存的恶意资源仍然有效，因为浏览器根本不会请求服务器获取新版本。这种攻击特别适合针对CDN节点缓存，一旦CDN边缘节点缓存了恶意版本，所有访问该节点的用户都会受到影响。

实际案例中，攻击者经常利用JSONP接口或第三方脚本加载器中的版本号参数。例如某个统计脚本的加载代码为：

服务器端未对 v 参数做任何过滤，攻击者直接构造 v=1';alert(1);// 即可注入恶意代码。更危险的是，如果该脚本设置了长期缓存，这个注入会持续影响用户，形成一种另类的存储型XSS。

除了直接拼接在script标签的src属性中，版本号还可能出现在动态创建的脚本元素里。前端框架中常见如下模式：

const version = new URLSearchParams(location.search).get('v');
const script = document.createElement('script');
script.src = `/bundle.${version}.js`;
document.head.appendChild(script);

攻击者将版本号设置为 ../../evil 或带有特殊字符的路径，可能触发路径遍历或意外加载外部资源。如果版本号直接来自URL片段或Referer头，攻击面会进一步扩大。某些应用使用版本号作为缓存键写入localStorage，攻击者通过XSS修改本地存储中的版本标识，也能实现持久化控制。

模块加载器同样存在风险。以RequireJS为例，其配置中的urlArgs参数常用于添加版本号：

require.config({
    urlArgs: "v=" + getQueryParam('version')
});

如果getQueryParam函数未做安全处理，攻击者可以注入任意字符串，破坏模块路径或插入恶意代码。ES模块的动态import也面临类似问题，import("/module.${version}.js") 中的版本号若来自不可信来源，同样构成注入点。

第一道防线是严格的输入验证。版本号应当只允许数字、点号和短横线，使用白名单正则进行过滤。例如在PHP中：

if (!preg_match('/^[a-zA-Z0-9._-]+$/', $_GET['v'])) {
    header('HTTP/1.1 400 Bad Request');
    exit;
}

更安全的做法是完全避免从用户可控输入中获取版本号。版本号应当由构建系统自动生成，通过配置文件或服务端渲染注入到页面中，而非从URL参数读取。如果必须从URL获取，应使用服务端映射表，将用户看到的版本标识映射为实际的文件路径，而非直接拼接字符串。

内容安全策略是防御XSS的兜底措施。配置严格的CSP头，禁止内联脚本执行，限制脚本来源域名：

Content-Security-Policy: script-src 'self' https://trusted-cdn.example.com;

这样即使攻击者成功注入了script标签，浏览器也会拒绝加载执行。配合nonce或hash机制，可以进一步细化脚本加载控制。Subresource Integrity也是关键防护手段，为每个脚本标签添加integrity属性：

浏览器会验证加载资源的哈希值是否匹配，即使版本号被篡改，只要文件内容与预期不一致，脚本就不会执行。

针对缓存投毒，需要重新审视静态资源的缓存配置。对于HTML页面本身，应当设置较短的缓存时间或使用协商缓存，避免页面中的版本号引用被长期缓存。静态资源可以使用内容哈希而非版本号命名，例如 app.abc123.js 而非 app.js?v=1.2.3。文件内容变化时哈希必然改变，从机制上消除了版本号注入的可能。

现代构建工具都支持文件名哈希输出。Webpack配置中设置 output.filename 为 [name].[contenthash].js，每次构建只有内容变化的文件会获得新哈希。这种方案不仅安全，还能实现更精细的缓存控制。如果必须使用版本号参数，应在服务端对版本号做签名校验。生成版本号时附加HMAC签名，服务端验证签名通过后才返回对应资源：

// 生成带签名的版本号
$version = '1.2.3';
$signature = hash_hmac('sha256', $version, $secretKey);
$url = "/app.js?v={$version}&s={$signature}";

// 验证签名
$valid = hash_equals(
    hash_hmac('sha256', $_GET['v'], $secretKey),
    $_GET['s']
);

CDN层面也需要配置防护规则。在CDN控制台设置URL参数过滤，拒绝包含特殊字符的请求。配置边缘函数对版本号参数做正则校验，不匹配的请求直接返回403状态码。同时监控CDN日志中异常的版本号请求模式，及时发现攻击尝试。

开发阶段就应建立安全编码规范。禁止使用用户输入拼接脚本URL，所有版本号从构建变量或服务端API获取。代码审查中重点检查动态脚本加载逻辑，确保没有将URL参数、路径片段或任何用户可控数据直接拼接到资源地址中。使用ESLint的no-unsafe-innerhtml规则和Content-Security-Policy报告模式，在开发阶段捕获潜在风险。

对于第三方脚本加载，建立供应商安全评估机制。要求第三方提供SRI哈希值，并在script标签中强制启用。监控第三方脚本的版本变化，任何未经通知的版本更新都应触发安全告警。定期使用Subresource Integrity验证工具扫描页面，确保所有脚本标签都配置了正确的integrity属性。

服务端渲染的应用需要特别注意模板注入风险。模板引擎中输出版本号时，必须使用上下文感知的转义函数。在Node.js的EJS模板中，使用 <%= 会自动转义HTML实体，而 <%- 会原样输出，后者绝不可用于用户可控数据。类似地，Python的Jinja2模板中应使用 {{ }} 自动转义语法，避免使用 safe 过滤器处理不可信输入。

部署运行时监控机制，检测页面中异常的脚本加载行为。通过MutationObserver监听DOM中新增的script标签，检查其src属性是否符合预期格式。将异常上报到安全监控平台，设置告警规则。同时监控用户浏览器中缓存的资源版本分布，如果发现大量用户持有非官方发布的版本号，可能意味着缓存投毒攻击正在进行。

建立缓存清除预案。当确认发生缓存投毒后，需要立即更新静态资源的版本号或哈希值，并在服务端配置旧版本资源的强制失效规则。对于CDN缓存，使用purge接口清除所有边缘节点的恶意缓存副本。向受影响用户推送缓存清理通知，引导用户手动清除浏览器缓存或使用Clear-Site-Data响应头强制清除：

Clear-Site-Data: "cache", "cookies"

静态资源版本号防缓存XSS是一个典型的将工程便利性与安全性对立起来的案例。版本号机制本身没有问题，问题在于实现方式是否考虑了安全边界。通过内容哈希替代版本号参数、严格的输入验证、CSP和SRI多重防护，以及完善的监控响应体系，可以在享受缓存优化收益的同时，将安全风险控制在可接受范围内。安全人员应当将这类攻击向量纳入常规的渗透测试检查项，前端工程师则需要在架构设计阶段就将安全约束作为版本管理的核心需求之一。