PHP文件上传绕过_PHP文件上传安全绕过技巧

$_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），彻底剥离原始文件名语义
• 绝不动态包含用户上传的任何文件，无论扩展名或内容是否“干净”

文件上传的安全不是靠某一个检查点守住的，而是上传路径隔离、文件名净化、存储位置限制、执行环境隔离四层叠加的结果。漏掉任意一层，都可能让绕过成为现实。