PHP文件上传安全咨询：非Web目录存储任意文件是否安全？

首先得说，你这种架构比直接把uploads放在Web可访问目录里安全太多了——毕竟恶意PHP脚本没法被直接访问执行，从根源上切断了最常见的文件上传攻击路径。但也别掉以轻心，还是有几个潜在风险可能威胁到服务器安全，得逐个排查：

1. 路径遍历漏洞是头号风险 #

如果你的download.php里，是通过id直接拼接文件路径（比如$file = "/var/uploads/" . $_GET['id']），那攻击者很容易构造id=../etc/passwd这种参数，让脚本读取服务器的敏感系统文件。哪怕你觉得自己做了过滤，比如替换../，也可能被绕过（比如..//或者URL编码后的%2e%2e%2f）。

正确做法：

• 用数据库存储每个上传文件的id和对应的真实路径（比如上传时生成唯一ID，把路径存在DB里），通过ID查路径，完全避免用户输入和路径的直接拼接。
• 一定要做路径校验：拿到最终文件路径后，用realpath()解析出绝对路径，然后检查这个路径是否在/var/uploads目录的范围内（比如用strpos($realPath, "/var/uploads/") === 0）。

2. 文件类型与命名的额外防护 #

你提到知道可能上传病毒，但服务器本身的安全也要注意：

• 即使文件不在Web根外，万一后续服务器配置出问题（比如某个脚本不小心把上传目录挂载到Web根下），或者download.php被攻破，恶意脚本还是有被执行的可能。所以建议重命名上传文件：比如生成随机字符串（不要用用户原文件名），去掉后缀或者统一用安全后缀（比如.dat）。
• 严格校验文件类型：不要只看后缀，要检查文件头（比如图片文件的FF D8 FF开头），或者用finfo函数检测MIME类型，拒绝上传.php、.sh、.py这类可执行脚本文件。

3. 目录与文件权限必须锁死 #

Web服务器进程（比如www-data）对/var/uploads目录的权限要最小化：

• 目录权限设为750：所有者可以读写执行，组用户只读执行，其他用户无权限。
• 文件权限设为640：只有所有者能写，Web进程只读，完全去掉执行权限（哪怕是脚本文件，没有执行权限也没法被直接运行）。
• 确保/var/uploads的所有者不是Web服务器用户，而是单独的上传用户，避免Web进程意外修改或删除文件。

4. download.php本身的细节要做好 #

• 响应头必须设置正确：强制下载的话，要设置Content-Disposition: attachment; filename="xxx"，同时Content-Type设为application/octet-stream，这样浏览器只会下载文件，不会尝试解析执行。
• 输出文件前要清空缓冲区：避免之前的输出（比如空格、报错信息）污染文件内容，或者导致响应头失效。可以用ob_clean()和flush()处理。
• 处理错误情况：比如ID对应的文件不存在、路径校验失败时，要返回404或错误信息，不要输出任何敏感内容。

5. 服务器层面的额外防护 #

• 开启SELinux或AppArmor：这类安全模块可以限制Web进程的访问范围，哪怕download.php被绕过，也没法访问/var/uploads之外的目录，更没法执行文件。
• 定期扫描上传目录：用ClamAV这类工具扫描恶意文件，及时清理病毒或木马。

总结 #

这种架构是文件上传场景下的最佳实践之一，只要做好上面的几点防护，服务器本身被恶意文件侵害的概率会非常低。核心就是：绝对不让用户输入直接关联到文件路径，锁死权限，做好校验，从多个层面堵住漏洞。

内容的提问来源于stack exchange，提问作者cantsay