上传接口的「白名单扩展名」挡不住 svg.php 与 SVG 内嵌脚本：内容校验、存储隔离与渲染上下文三层加固清单

作者：温清和-529｜5 年安全工程师，专注安全加固与风险防范 栈：Spring Boot 3.2.4 / Spring Security 6.3、Nginx 1.25、Go 1.21（对照实现）、MinIO RELEASE.2024-01-02、file 5.45 结论先行：文件上传和文件下载是同一枚硬币的两面，但攻击面恰好相反。下载侧的根因是「校验的是字符串、OS 打开的是路径」，上传侧的根因是「校验的是扩展名、浏览器执行的是内容」——你拦的是 .txt 这个后缀名，而浏览器渲染的是文件里那句 <script>。这条缝，就是上传侧所有绕过的藏身之处。

一、现象与背景：一个「只收图片」的头像接口，成了存储型 XSS 的入口

去年给一家做企业协作 SaaS 的客户（约 8 万注册用户、Spring Boot 3.2 + Nginx 1.25）做季度安全复盘。目标是员工头像上传接口 POST /api/v1/avatar，业务定位「只收 jpg/png」。安全同学很自信：「我们白名单了扩展名，只放行 .jpg .jpeg .png。」

我做了三件事，全程不到 20 分钟：

1. 把一段 <script> 包进一张 SVG，文件名改成 avatar.svg，直接被拒（白名单生效）；
2. 换成 avatar.png，但文件内容其实是 SVG（magic bytes 是 <?xml），上传成功——因为服务端只看了 filename 头里的后缀，没看内容；
3. 把这张「png 壳、SVG 核」的文件存到了和正常头像同一个桶 avatars/ 下，前端 <img src> 直接引用——浏览器按 <img> 的语义不执行 SVG 脚本，但一旦有人用 <object>/<iframe>/富文本编辑器加载同一 URL，脚本就跑起来了。

最终影响面：存储型 XSS 一条链（头像 URL 被富文本消息引用即可触发），加上「内容≠扩展名」这个口子让白名单形同虚设。更扎心的是：WAF 一条告警都没报——因为它拦的是「扩展名是否危险」，而我传的 .png 在它眼里干干净净。

这套代码上线 14 个月，期间被内部渗透测到 2 次、都当「误报」关掉了。

二、根因：上传侧的信任边界在「内容语义」，不在「文件名」

先讲机制，才能理解为什么「白名单扩展名」不够。

上传一个文件，系统里其实有三个独立的事实，而大多数实现只校验了第一个：

| 层 | 事实 | 谁说了算 | 多数实现 | |---|---|---|---| | 1 | 文件名 / 扩展名 | 客户端（Content-Disposition） | ✅ 只校验这个 | | 2 | 魔数 / 内容结构（magic bytes、MIME） | 文件本体 | ❌ 基本不看 | | 3 | 渲染 / 执行上下文（存哪、怎么读） | 服务端存储 + 前端引用方式 | ❌ 默认「存了就能信」 |

攻击者能完全控制第 1 层（改个后缀名零成本），所以任何只锚定第 1 层的判定都是可绕的。真正决定「这个文件能不能执行/注入」的是第 3 层——它落在哪、被谁以什么上下文加载。

具体到绕过路径，有两条最常被忽略：

• 双扩展名 / 内容伪装：evil.svg.php、或 .png 后缀装 SVG/HTML。Nginx 的 cgi.fix_pathinfo 一旦开启，/uploads/evil.svg.php 会被当成 evil.svg + 参数 php 路由到 PHP 处理器——扩展名白名单在这里直接失效，因为决定执行的是「最后一段能被解析成脚本的扩展名」。
• SVG / GIF89a 内嵌脚本：SVG 是 XML，天然能带 <script>、<foreignObject>、onload=；GIF 头后跟 HTML 也能被某些旧浏览器部分解析。你拦不住「内容里写什么」，除非你在渲染侧把它关进 <img> 语义（<img> 不执行脚本）或 CSP 里禁 object-src/script-src 对该域。

一句话：下载侧防「读错文件」，上传侧防「读对文件但执行了不该执行的内容」。 前者靠规范化路径，后者靠内容校验 + 存储隔离 + 渲染上下文，三件事缺一不可。

三、具体做法：三层加固，每层都能独立挡掉一类绕过

层 1：内容校验（别信扩展名，信魔数）

Spring Boot 侧，用 file 的语义做魔数/结构校验，而不是 String endsWith：

// ❌ 只信扩展名：可被 .png 装 SVG 绕过
if (!name.toLowerCase().endsWith(".jpg") && !name.toLowerCase().endsWith(".png")) {
    throw new BizException("仅支持图片");
}

// ✅ 校验内容结构：读前 N 字节判真实类型
byte[] head = in.readNBytes(64);
String real = detectMagic(head);   // PNG=89 50 4E 47，JPEG=FF D8 FF，GIF=47 49 46，SVG/HTML 以 "<?xml"/"<" 开头
if (!ALLOWED.contains(real)) {
    throw new BizException("文件内容与声明类型不符");   // 命中「png 壳 SVG 核」
}

Go 侧对照（image.DecodeConfig 只认 PNG/JPEG/GIF，SVG 直接不识别，天然挡掉一类）：

cfg, _, err := image.DecodeConfig(bytes.NewReader(head))
if err != nil { // SVG/HTML 会在这里失败 → 拒绝
    http.Error(w, "not a raster image", http.StatusUnsupportedMediaType)
}

要点：白名单 + 魔数双校验，且以「内容」为准、扩展名只作提示。

层 2：存储隔离（让「存了」不等于「能执行/能注入」）

• 独立桶 / 独立目录：用户上传一律进 user-uploads/，和应用静态资源、和可执行目录物理分开。
• 强制改名为不可预测文件名：uuid5(namespace, tenant+ts)+.真实扩展，杜绝 evil.svg.php 这种「文件名即攻击」的写法。
• Nginx 侧把上传目录禁脚本执行（这是挡双扩展名的关键一刀）：

location ^~ /user-uploads/ {
    # 该目录一律按静态文件处理，任何 .php/.jsp 后缀都不进 CGI
    types { } default_type application/octet-stream;
    include mime.types;
    # 明确禁止任何脚本处理器接管
    if ($request_uri ~* \.(php|jsp|asp|aspx|sh|cgi)$) { return 403; }
    # 关键：关掉 fix_pathinfo 语义，禁止把 /a.svg.php 解析成 /a.svg + 参数
    # （配合 CGI 层）
}

• 响应头钉死渲染语义：对 user-uploads/ 强制 Content-Type 按真实类型给，并加 Content-Disposition: inline; filename="..."；对 SVG 额外下发 X-Content-Type-Options: nosniff，防止浏览器「猜」成 HTML 执行。

层 3：渲染上下文（最后一道、也最容易被漏的一道）

• 前端一律用 <img> 渲染头像，禁用 <object>/<embed>/<iframe> 直接指向上传桶——<img> 语义天然不执行 SVG 脚本。
• CSP 里把上传域关进 img-src，不放行 object-src / frame-src / script-src 到该域：

Content-Security-Policy: img-src 'self' https://cdn.user-uploads.example; object-src 'none'; frame-ancestors 'self'

• 富文本编辑器要引用外部资源时，走「服务端先转码成 PNG 再存」的链路（rsvg-convert / sharp），把 SVG 的脚本能力在入库前就剥掉。

四、踩过的坑 / 反直觉之处

1. file 命令会骗人：file 对「PNG 头 + SVG 体」可能报 SVG，也可能报 PNG graphic data（取决于它读到哪段）。所以魔数校验不能只取第一个 magic，要按「声明类型 → 期望 magic」做正向比对，而不是「file 说啥信啥」。
2. Nginx cgi.fix_pathinfo 是隐藏雷：很多团队从没改过它，默认 on。一旦上传目录里有 .php 后缀文件，/a.svg.php 会被路由成 PHP 脚本执行——扩展名白名单 + 魔数校验都救不了，因为请求根本没走「读文件」而是走「执行脚本」。这一刀只能在 Nginx/CGI 层关掉。
3. <img> 不执行脚本是「浏览器行为」不是「安全保证」：它依赖的是渲染上下文，而不是文件本身。同一个 URL，<img> 里安全、<object> 里就是 XSS。所以渲染侧的约束（CSP + 前端规范）才是根，存哪、怎么读才是因——只加固服务端、不管前端怎么引用，等于只锁了门没锁窗。
4. 改文件名 ≠ 安全：光把 evil.svg.php 重命名成 uuid.png，如果桶还能被 <object> 加载、或 Nginx 还路由脚本，照样打穿。改名只解决「文件名即攻击」，不解决「内容即攻击」。

五、结论与可复用清单

上传侧安全 = 内容校验（不信扩展名）× 存储隔离（存了≠能执行）× 渲染上下文（谁怎么读），三者相乘，任何一项为 0 整体就为 0。

可复用清单（按优先级）：

• [ ] 魔数/结构正向比对，扩展名只作提示；SVG/HTML 对「只收图片」的接口一律拒绝或转码入库
• [ ] 上传文件强制 UUID 改名 + 独立桶/目录，与可执行目录物理隔离
• [ ] Nginx 对上传目录 return 403 一切脚本后缀，并确认 cgi.fix_pathinfo off
• [ ] 上传目录响应头 X-Content-Type-Options: nosniff + 按真实类型给 Content-Type
• [ ] 前端头像只用 <img>；CSP object-src 'none'、img-src 限定上传域
• [ ] 富文本引用外部资源走服务端转 PNG 链路（sharp/rsvg-convert），入库前剥掉脚本能力
• [ ] 审计：拉一次上传桶全量文件，file + 魔数双重比对「声明类型 vs 真实内容」，把历史脏数据清掉

一句话收尾：下载侧你拦的是「能不能读到」，上传侧你拦的是「读到了会不会执行」——前者是路径问题，后者是语义问题，用错了工具箱，白名单就是张纸。