$_FILES'file'完全不可信，因其由浏览器伪造，服务端必须用finfo_file()校验文件头，并配合扩展名严格解析、上传目录禁解析、重命名存储及Web目录外隔离等多重防御。
为什么 $_FILES 的 type 字段完全不可信
浏览器提交的 $_FILES['file']['type'] 是前端 JavaScript 或表单中 enctype 生成的 MIME 类型，服务端未做任何校验就直接信任它，等于把文件类型判断权交给了攻击者。比如上传一个 shell.php，只要前端伪造 Content-Type: image/jpeg，PHP 就会记录为 image/jpeg —— 实际后缀和内容完全不受影响。
实操建议：
- 绝不能用
$_FILES['file']['type']做白名单过滤 - 若需 MIME 判断，改用
finfo_file()在服务端真实读取文件头（注意：仍需配合其他手段，因为头部可伪造） - 最稳妥方式是忽略所有客户端传来的类型信息，只依赖服务端解析 + 文件扩展名黑名单 + 内容检测
绕过扩展名检查的常见手法及防御要点
很多开发者只简单用 pathinfo($filename, PATHINFO_EXTENSION) 取后缀，再比对白名单，这极易被绕过。攻击者会利用大小写、多点、空字节、编码等方式欺骗解析逻辑。
典型绕过示例：
立即学习“PHP免费学习笔记（深入）”；
-
shell.PHP→ 大小写绕过（Windows/IIS 对大小写不敏感） -
shell.php.jpg→ 多点截断（部分旧版 Apache + mod_php 会取最后一个点后的后缀） -
shell.php%00.jpg→ 空字节截断（PHP 5.3.4 之前，move_uploaded_file()遇到%00会截断） -
shell.php.或shell.php→ 特殊空白字符干扰pathinfo解析
防御建议：
- 使用
strrchr()或正则严格提取「最后一个点之后且不含空白/控制字符」的扩展名 - 统一转为小写后再比对白名单
- 禁用危险扩展名时，必须同时禁用其变体：
php3、phtml、php5、phar、htaccess等 - 上传目录禁止解析 PHP，例如 Nginx 中配置
location ~ \.php$ { deny all; }
getimagesize() 不是安全检查的银弹
有人误以为调用 getimagesize() 能验证图片合法性，从而允许上传。但该函数仅检查文件头是否符合图像格式规范，无法阻止在合法图片末尾追加 PHP 代码（即“图片马”），或利用图像解析器漏洞（如 GD 库、ImageMagick 的 CVE）触发远程执行。
实操注意事项：
-
getimagesize()返回非 false ≠ 文件安全，仅表示它“看起来像图” - 若业务必须处理用户图片，应重绘图像（如用
imagecreatefromjpeg()+imagejpeg()）丢弃原始数据，但这也不能 100% 拦截所有隐写或解析漏洞 - 更可靠做法是：上传后保存为随机名 + 固定安全扩展（如
.bin），并存放在 Web 目录外；如需展示，走代理脚本读取并设置正确Content-Type
为什么把文件移到 /tmp 后再处理仍可能出问题
有些方案认为“先用 move_uploaded_file() 移到系统临时目录，再用 finfo / getimagesize 检查，没问题再复制到目标位置”，看似严谨，但忽略了两个关键风险：
- 临时目录权限若配置不当（如
/tmp全局可写），攻击者可能提前创建同名符号链接，导致move_uploaded_file()写入任意路径（Linux 下需开启open_basedir或使用upload_tmp_dir隔离） - 即使检查通过，若后续用
include、require或file_get_contents()加载该文件，而文件名可控，仍可能触发 LFI 或代码执行（尤其配合php://filter等伪协议）
真正安全的落地方式是：
- 设置独立的、Web 不可访问的上传临时目录（如
/var/www/uploads/tmp），并确保属主为 Web 进程用户，权限为0700 - 上传后立即重命名（如
sha256(file_content).bin），彻底剥离原始文件名语义 - 绝不动态包含用户上传的任何文件，无论扩展名或内容是否“干净”
文件上传的安全不是靠某一个检查点守住的，而是上传路径隔离、文件名净化、存储位置限制、执行环境隔离四层叠加的结果。漏掉任意一层，都可能让绕过成为现实。
