PHP7.0文件上传防护的五大误区：仅校验$_FILES'file'、用黑名单代替白名单、直接移至Web目录并保留原名、依赖前端JS限制、未重命名且未隔离存储路径，均易导致RCE。
PHP7.0 版本文件上传漏洞的防护，常因沿用旧习惯或理解偏差，陷入几个看似合理、实则危险的误区。这些误区在真实攻防场景中已被反复验证为高危缺口，尤其在 PHP7.0 这类已停止官方支持（2018年12月终止维护）、缺乏安全更新的版本上，风险被进一步放大。
只校验 $_FILES['file']['type'] 就认为安全
这个字段完全由客户端浏览器提供，可轻易伪造。攻击者只需修改 HTTP 请求中的 Content-Type 头（如将 image/jpeg 改为 text/plain 或直接构造 multipart 数据），就能绕过所谓“MIME 类型检查”。PHP7.0 并不自动校验文件真实类型，该值仅作参考，绝不能作为判断依据。
用简单后缀名黑名单（如屏蔽 .php）代替白名单
黑名单天然存在遗漏风险：.phtml、.php5、.php3、.phar、.htaccess（配合解析漏洞）等扩展名均可能被 PHP 引擎执行。PHP7.0 对部分非常规扩展的支持未做严格限制，且 Apache/Nginx 配置差异会扩大可利用面。真正有效的做法是仅允许明确安全的扩展名，例如 ['jpg', 'jpeg', 'png', 'gif', 'pdf']，其余一律拒绝。
上传后直接移动到 Web 可访问目录并保留原始文件名
这是最典型的 RCE（远程代码执行）温床。一旦攻击者上传 shell.php.jpg 并成功绕过扩展名校验（例如服务端只截取最后一个点后的部分），而服务器又恰好配置了 .jpg 的 PHP 解析规则（如 Nginx 的 fastcgi_split_path_info 配置错误），恶意代码即可执行。更危险的是，原始文件名还可能引发路径遍历（如 ../../shell.php）或覆盖关键文件。
依赖前端 JavaScript 限制上传类型
前端校验纯属用户体验优化，对攻击者毫无约束力。任何能发 HTTP 请求的工具（curl、Burp Suite、Python 脚本）都可跳过前端逻辑，直传恶意文件。PHP7.0 的服务端代码若未做独立、严格的二次验证，前端限制形同虚设。
未重命名文件 + 未隔离存储路径
不重命名意味着文件 URL 可预测（如 uploads/evil.php），攻击者上传后可立即访问；不隔离存储（如把 uploads/ 放在 Web 根目录下）等于主动开放执行入口。正确做法是：生成随机文件名（如 sha256(uniqid().time()).png），并将文件存于 Web 根目录之外（如 /var/data/uploads/），再通过受控脚本（如 download.php?id=xxx）提供安全下载。
