去年有个朋友的防范公司被拖库了。攻击者没用什么高深漏洞，上传式就是漏洞找到一个上传接口，传了个伪装成图片的防范PHP文件，然后直接访问它。上传式服务器权限拿得干干净净。漏洞事后复盘，防范代码里其实做了后缀名白名单，上传式但只检查了文件名最后一个点之后的漏洞部分——攻击者传的是 shell.php.jpg，白名单里有 jpg，防范放行。上传式就这么简单。漏洞

上传漏洞的防范可怕之处在于，它往往不是上传式单独存在的。一个上传点配合解析漏洞、漏洞配合路径穿越、配合文件包含，就能把低危变成高危。很多人把注意力放在“怎么写好白名单”上，方向就偏了。

别让文件落在能执行的地方

最有效的防范方式，是让上传的文件根本没有机会被当作代码执行。听起来像废话，但绝大多数人没做到。

具体怎么做？把上传目录和Web根目录彻底分开。文件存到 /data/uploads/，这个路径不在任何域名或虚拟主机的 document root 下。用户要访问文件，走一个专门的下载接口，由后端读取文件流返回。这样即使传上来一个 .jsp 或者 .php，它也只是一坨二进制数据，永远不会被解析器碰到。

有人会说这样性能差、CDN不好接。那就退一步：上传目录放在Web根目录下，但通过Nginx配置彻底禁止该目录下的脚本执行。比如：

location ^~ /uploads/ {  location ~ \.(php|php5|jsp|asp|aspx|py|pl|cgi)$ {  deny all; } }

这比在应用层做后缀名检查可靠得多。应用层的检查可以被绕过——大小写、双写后缀、%00截断、.htaccess 重写，花样太多了。Web服务器层面的 deny 是硬性的。

文件名和路径，一个字符都别信

用户上传时带的文件名，只能当作参考，不能直接用于存储。我见过有人直接把 $_FILES['file']['name'] 拼到路径里，结果攻击者传了个 ../../../../etc/cron.d/malicious，直接写进系统计划任务。

正确的做法是：服务端生成一个新文件名，用 UUID 或者时间戳加随机串，后缀根据实际检测到的文件类型来决定。原始文件名存在数据库里，只用于展示和下载时的 Content-Disposition。

路径拼接也要小心。不要用用户输入去拼路径，哪怕只是文件名部分。生成的文件名里只允许 [a-zA-Z0-9_-] 和点，其他字符一律替换掉。

内容检测比后缀检测有用，但别迷信

检查文件头（magic bytes）能挡住一部分伪装文件。比如真实的 JPEG 以 FF D8 FF 开头，PNG 以 89 50 4E 47 开头。但攻击者可以在恶意文件前面加上这些字节，做成图片马。所以内容检测要配合其他手段。

更实际的做法是：对图片用 GD 或 ImageMagick 重新渲染一遍。重新生成后的图片，即使里面藏了 PHP 代码，也会被破坏掉。这个操作还能顺便去掉 EXIF 里的恶意 payload。

对于非图片文件，比如 PDF、Office 文档，如果业务允许，可以放到对象存储里，用预签名 URL 访问。这样文件根本不经过你的服务器，攻击面直接砍掉一大块。

权限和隔离是最后一道墙

假设前面全被绕过了，攻击者真的传上来一个可执行文件并且能访问到。这时候如果 Web 进程以低权限用户运行，上传目录没有执行权限，数据库连接使用最小权限账户，攻击者能做的事也很有限。

Linux 下给上传目录挂载 noexec 选项，或者用 chmod 0644 去掉执行位。Windows 下配置 IIS 的请求筛选，禁止上传目录下的脚本映射。这些是操作系统层面的防线，比应用层可靠。

还有一点容易忽略：上传目录不要和主站同域。用独立的域名或者CDN域名来提供文件访问，这样即使传上来一个 HTML 文件，也无法通过同源策略窃取主站 Cookie。

说到底，上传漏洞的防范不是靠某一个“终极方案”，而是靠多层防御的叠加。任何单点检查都有被绕过的可能，但把文件存储位置、服务器配置、文件重命名、内容处理、权限隔离这几层都做扎实，攻击者要突破的成本就高到不划算了。

我自己的习惯是：拿到一个上传功能，先问文件存哪、怎么访问、用什么身份运行。这三个问题的答案，基本就决定了这个功能的安全水位。