去年有个CTF题目，中间Nginx配了PHP-FPM，析漏上传一个名为shell.jpg的中间文件，内容是析漏一句话木马。访问/upload/shell.jpg/x.php，中间服务器返回了木马执行结果。析漏这不是中间配置失误，是析漏Nginx对PATH_INFO的处理方式出了岔子——它把.jpg后面的/x.php当作PATH_INFO传给FastCGI，PHP-FPM一看后缀是中间.php，直接当PHP脚本跑了。析漏

这类问题统称中间件解析漏洞。中间核心矛盾在于：中间件判断文件类型用的析漏规则，和后端处理器实际执行的中间规则，两者对不上。析漏谁说了算？中间没人说得清，于是漏洞就来了。

Nginx的fastcgi_split_path_info配置陷阱

Nginx处理PHP请求时，常见配置长这样：

location ~ \.php$ {  fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_pass 127.0.0.1:9000; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PATH_INFO $fastcgi_path_info; }

正则^(.+\.php)(/.+)$看着没问题，问题出在location ~ \.php$这个匹配规则上。它只要求URI以.php结尾，那/upload/shell.jpg/x.php是不是也满足？满足。Nginx把整个路径丢给PHP-FPM，PHP-FPM拿到SCRIPT_FILENAME，发现文件shell.jpg/x.php不存在，但如果开了cgi.fix_pathinfo=1（PHP默认开启），它会往前回溯，找到shell.jpg，然后把它当PHP执行。

修复方式有两种。一是关掉cgi.fix_pathinfo，二是把Nginx的location改成location ~ \.php$加上try_files $uri =404。后者更常见，但很多人配了fastcgi_split_path_info却忘了加try_files，等于门锁了窗户还开着。

Apache的AddHandler与多后缀名

Apache有个经典问题：AddHandler application/x-httpd-php .php这行配置，会让Apache把任何包含.php后缀的文件都交给PHP处理。上传shell.php.jpg，Apache从右往左解析后缀，遇到.jpg不认识，继续往左，看到.php，好，交给PHP。文件确实叫shell.php.jpg，但执行的是PHP代码。

更离谱的是shell.php.abc这种。Apache 2.x在mod_mime模块下，如果.abc没有映射，它会继续往前找，最终匹配到.php。这跟Nginx的PATH_INFO问题本质相同——解析器在“文件到底是什么类型”这件事上，给出了多个答案。

我见过一个真实案例：某CMS上传目录禁止.php后缀，但允许.php5。Apache配置里AddHandler application/x-httpd-php .php .php5，攻击者上传shell.php5，直接执行。防御方以为禁了.php就万事大吉，实际上Apache认的是handler，不是后缀名。

IIS的短文件名与分号截断

IIS 6.0时代有两个经典漏洞。一是短文件名猜解：Windows把shell.php存成SHELL~1.PHP，攻击者通过~符号枚举文件。二是分号截断：shell.asp;.jpg，IIS 6.0解析时遇到分号就截断，实际执行shell.asp。这两个漏洞在IIS 7之后基本修复，但短文件名问题在部分Windows Server上依然存在，只是利用难度高了。

IIS 7的FastCGI模式也有类似Nginx的问题。如果配置了php.ini里的cgi.fix_pathinfo=1，访问/upload/shell.jpg/x.php同样可能触发解析。微软的修复方案是打补丁，但补丁只改了IIS的处理逻辑，PHP-FPM那边没动，所以换个中间件照样出问题。

根源在哪

中间件解析漏洞的根源不是某个中间件写得烂，而是HTTP请求路径到文件系统路径的映射过程太复杂。URI可以带参数、带PATH_INFO、带多后缀，中间件要猜，后端也要猜，两边猜的规则不一致，攻击者就在缝隙里塞进一个可执行文件。

防御思路其实很简单：让中间件和后端对“什么文件可以执行”达成一致。Nginx加try_files，Apache用FilesMatch精确匹配，IIS关掉fix_pathinfo。但现实是，很多老系统跑着十年前的配置，没人敢动。漏洞就这么留着，等下一个CTF选手或者攻击者来发现。