商城首页欢迎来到中国正版软件门户

您的位置: 首页 > 文章列表 > 编程开发 > phpEnv配置Nginx防止目录遍历漏洞 phpEnv安全配置

phpEnv配置Nginx防止目录遍历漏洞 phpEnv安全配置

  发布于2026-07-10 阅读(0)

扫一扫,手机访问

phpEnv这玩意儿,默认情况下其实是跟Apache绑定的,Nginx更像是它的一个“选装件”,需要你手动去翻牌子。但问题就出在这儿:一旦你手痒,在phpEnv控制面板里把Web服务切换成了Nginx,它自带的那个配置,简直可以说是“裸奔”级别的——极度简化,毫无加固。什么autoindex可能意外开着,rootalias混用,甚至对../路径穿越都没做任何过滤,这几乎等于把目录遍历漏洞的大门给焊死了。所以,这篇东西,就是专门给那些已经在用或者打算用phpEnv+Nginx组合的朋友们看的,咱们得把这几处硬伤一次性修好。

确认当前用的是 Nginx 而非 Apache

在动手改配置之前,第一件事是确认自己没搞错对象。很多人信誓旦旦地说“我在配phpEnv的Nginx”,结果发现服务的压根儿就是Apache,这就尴尬了。怎么确认呢?步骤很简单:

  • 打开phpEnv控制面板,点右上角「设置」,在「Web 服务」那里选「Nginx」,然后重启服务。
  • 检查端口。Apache默认占着80和443端口,Nginx启动后也得监听同样的端口。打开命令行敲个netstat -ano | findstr :80,看看进程名是nginx.exe 还是 httpd.exe,后者说明Apache还在干活。
  • 最直接的办法,访问 http://localhost/nginx_status(前提是启用了stub_status模块),或者看phpEnv托盘图标的状态提示。

这一步没确认好,后面改得再花哨也是白搭。

关闭 autoindex 并禁用敏感路径匹配

phpEnv自带的Nginx配置,最典型的问题就是没关autoindex,也缺乏基础的路径过滤。漏洞是怎么来的?就是这些细节没做到位。解决起来也不复杂,直接在server块的最顶部,加上下面这两段:

location ~ /\.\./ {    deny all;    return 403;}location ~ /\.(ht|git|env|conf|log|bak|swp)$ {    deny all;}

这里有个关键点要记住:~ /\.\./ 这条规则,必须写在所有其他location规则的最前面。为什么?因为Nginx选择location时是有优先级的,如果后面有更具体的规则(比如location /static/),这个通用规则就可能被绕过。至于deny allreturn 403,写一个就行,但为了保险起见,建议两个都写上,以防某些旧版Nginx对deny指令的解析出问题。

root 与 alias 别混用,优先用 root + try_files

在phpEnv的示例配置里,你经常会看到这种写法,看着眼熟不?

location /uploads/ {    alias D:/phpEnv/www/uploads/;}

这种写法极其危险。攻击者只要构造一个/uploads/../etc/passwd的请求,就能轻松绕过alias的路径限制,直接访问到www目录之外的文件。正确且安全的做法,是统一用root,再配合try_files来截断非法路径:

location /uploads/ {    root D:/phpEnv/www;    try_files $uri =404;}

这样一来,当请求/uploads/../etc/passwd时,Nginx拼出的物理路径是D:/phpEnv/www/uploads/../etc/passwd,但try_files指令会直接检查这个文件是否存在——不存在?那就返回404,路径结构自然就不会暴露了。这里还有几个小细节:root路径末尾不要加斜杠,但location末尾必须加(比如/uploads/);千万别把root指向D:/C:/这种根分区;另外,Windows路径里的反斜杠\,在nginx.conf里必须写成正斜杠/,否则配置文件校验会直接报错。

检查 php-fpm 解析范围是否越界

目录遍历的漏洞可不只出现在静态文件上,PHP动态解析同样是一大风险点。phpEnv的Nginx默认PHP配置,经常会漏掉对SCRIPT_FILENAME的校验,比如下面这种:

location ~ \.php$ {    root D:/phpEnv/www;    fastcgi_pass 127.0.0.1:9000;    fastcgi_index index.php;    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;}

问题出在$document_root$fastcgi_script_name这个拼接上。如果攻击者请求的是/test.php/../etc/passwd,就有可能触发CVE-2013-4547这类经典漏洞。加固的方式也很明确:

  • 首先,确保php.ini里的cgi.fix_pathinfo=0。phpEnv默认是1,必须手动改过来。
  • 其次,在Nginx配置里,用正则对fastcgi_script_name做个限制,只允许它包含字母、数字、下划线和点。可以在SCRIPT_FILENAME那行前面加一句:if ($fastcgi_script_name ~ "..") { return 403; }
  • 最稳妥的办法,是把PHP的执行范围限定在明确的子目录下。比如,只允许/api//wp/下的PHP文件被执行,其他路径下的PHP请求一律拒绝。

最后必须提醒一句,Windows系统下的路径解析比Linux要松散得多,..%2e%2e..\/,甚至文件名末尾带个空格,都可能被攻击者利用来绕过检测。千万别凭“我本地测试没问题”就掉以轻心,用Burp Suite发个hex请求试试,真相往往很残酷。

本文转载于:https://www.php.cn/faq/2393442.html 如有侵犯,请联系zhengruancom@outlook.com删除。
免责声明:正软商城发布此文仅为传递信息,不代表正软商城认同其观点或证实其描述。

热门关注