finfo_file() 是唯一可靠的 MIME 校验方式，它直接读取临时文件二进制头识别真实类型；必须用 FILEINFO_MIME_TYPE 模式、校验 tmp_name 合法性、白名单匹配完整 MIME 字符串，并配合安全重命名与存储隔离。
finfo_file() 是唯一能信的 MIME 校验方式
靠 $_FILES['file']['type'] 判断文件类型，等于把服务器大门钥匙交到上传者手里。这个值来自浏览器发的 Content-Type 请求头，curl 或 Burp 一改就变；finfo_file() 则直接读取临时文件的二进制头，识别真实 MIME，绕过成本高得多。
- 必须用
finfo_open(FILEINFO_MIME_TYPE)—— 不能用FILEINFO_MIME，后者返回带编码的完整字符串（如image/jpeg; charset=binary），比对极易出错 - 调用前先检查
$_FILES['file']['tmp_name']是否存在、是否为合法上传临时文件，避免空值或路径遍历导致finfo_file()读取任意文件 - 白名单必须是完整 MIME 字符串，例如
'image/jpeg'，不能只写'jpeg'或'jpg' - 老旧环境可能未启用
fileinfo扩展，上线前务必执行extension_loaded('fileinfo')检查
exif_imagetype() 只能当快速初筛，绝不能单独使用
exif_imagetype() 快、轻量，但只看文件开头几个字节的魔数（如 JPEG 的 FF D8 FF），完全无法识别“图片+PHP 脚本”拼接的文件。攻击者用 cat good.jpg bad.php > evil.jpg 就能绕过。
立即学习“PHP免费学习笔记（深入）”；
-
false不代表非法，可能是合法但不支持的类型（比如某些带扩展块的 GIF） - 对 SVG 完全无效 ——
exif_imagetype()不解析 XML 结构，必须回退到finfo_file()或 XML 内容扫描 - 若业务需兼容 GIF87a/GIF89a，注意它遇到注释块或应用扩展块时可能误判
- 最多作为第一道过滤：先
exif_imagetype()快速排除明显非图文件，再用finfo_file()做最终确认
重命名必须丢弃原始文件名全部内容
用户上传 shell.php.jpg，你若用 pathinfo($name, PATHINFO_EXTENSION) 提取后缀，就会得到 jpg —— 这正是攻击者设计的陷阱。原始文件名一个字符都不能留。
- 生成新文件名推荐：
uniqid('up_') . bin2hex(random_bytes(8))，再拼上由 MIME 映射来的固定后缀（如image/png → '.png'） - 映射表必须严格一一对应：
'image/gif' => '.gif'，不能把非标准 MIME（如'image/x-png'）也映射成'.png'，应直接拒绝 - 文件名中禁止出现
..、/、\0、控制字符；清洗不如彻底不用 —— 但若真要清洗，可用preg_replace('/[^a-zA-Z0-9._-]/', '', $basename)
存储与执行隔离比校验更关键
哪怕 MIME 校验全对，只要文件存到 Web 可访问目录且该目录允许执行 PHP，上传漏洞就依然成立。校验只是防线之一，不是终点。
- 上传文件必须存到 Web 根目录之外（如
/var/uploads/），通过代理脚本或 CDN 回源提供访问 - 若必须放 Web 目录下，对应目录要禁用 PHP 执行（Nginx 配置
location ~ \.php$ { deny all; }，Apache 用php_flag engine off） - 临时文件
$_FILES['file']['tmp_name']在校验完成后必须立即移动（move_uploaded_file()），不能仅靠copy()或rename()，否则可能触发竞态条件 - 上传后不要依赖
getimagesize()或 GD 函数做二次验证 —— 它们可能触发图像解析器漏洞（如 CVE-2017-7983），finfo_file()已足够
最常被忽略的一点：MIME 白名单和后缀映射表必须硬编码在代码里，不能从配置文件或数据库读取 —— 否则一旦配置被污染或注入，整条防线瞬间崩塌。
