apache解析漏洞

2017年，解析Apache官方修了一个漏洞，漏洞编号CVE-2017-15715。解析问题出在AddType指令和换行符的漏洞配合上——文件名末尾如果带一个\x0A，Apache会把它当成PHP文件来解析。解析换句话说，漏洞你上传一个叫shell.php\x0A的解析文件，服务器上跑起来的漏洞就是PHP代码。这不是解析Apache第一次因为解析逻辑翻车，也不会是漏洞最后一次。

要理解这类漏洞，解析得先搞清楚Apache怎么判断一个文件该交给谁处理。漏洞它靠的解析是mod_mime模块，这个模块根据文件扩展名来分配handler。漏洞比如.php交给PHP解析器，解析.jpg当图片直接返回。听起来很直接，但问题在于：扩展名的判断规则比大多数人想的要宽松得多。

多扩展名的陷阱

Apache默认配置下，AddHandler application/x-httpd-php .php这行指令意味着任何以.php结尾的文件都会被PHP处理。注意，是“以.php结尾”，不是“扩展名等于php”。所以evil.php.jpg不会被解析——因为结尾是.jpg。但反过来，evil.jpg.php会被解析，这很正常。

真正有意思的是当多个扩展名同时存在时，Apache的处理顺序。它从右往左扫描，找到第一个认识的扩展名就停下来。但mod_mime有个特性：如果遇到不认识的扩展名，它会继续往左找。这就意味着shell.php.xyz这种文件，.xyz没人认识，Apache继续看.php，然后交给PHP处理。很多上传功能只检查最后一个扩展名，看到.xyz就放行了，文件落地后却被当成PHP执行。

我见过一个真实案例。某CMS的上传模块用黑名单过滤，禁止.php、.phtml等后缀。攻击者上传了payload.php.txt，后端检查.txt不在黑名单里，放行。但Apache配置里有一行AddHandler application/x-httpd-php .php .txt——运维为了图方便，把.txt也绑给了PHP。结果就是文件直接被执行。

换行符与正则的边界

CVE-2017-15715的成因更微妙。FilesMatch指令用正则匹配文件名，$在正则里默认匹配行尾。如果文件名是shell.php\x0A，正则\.php$会匹配成功，因为\x0A被当成了行尾。但文件系统层面，这个\x0A是文件名的一部分。上传时后端如果只检查字符串里有没有.php，可能会漏掉这个换行符，或者检查逻辑被绕过。Apache拿到文件后，正则匹配通过，交给PHP执行。

修复方式也简单：Apache 2.4.26之后，$默认只匹配字符串末尾，不再匹配换行符前的位置。但老版本还在跑，很多Docker镜像里的Apache版本压根没更新。

怎么防

最直接的办法是别让上传目录里的文件被执行。Nginx那边常用location ~* /uploads/.*\.php$ { deny all; }，Apache可以用<Directory>配合php_admin_flag engine off。但很多人图省事，上传目录和代码目录混在一起，那就只能靠白名单了。

白名单比黑名单靠谱。只允许.jpg、.png、.gif，其他一律拒绝。同时要检查文件内容——图片文件头是不是真的图片，别光看扩展名。还有一点容易忽略：上传后的文件名最好重命名，用随机字符串加固定后缀，别用用户提交的原始文件名。这样即使Apache解析逻辑有漏洞，攻击者也没法控制文件名里的扩展名顺序。

Apache的解析漏洞说到底是个设计问题：扩展名匹配太灵活，配置又太容易写错。运维写AddType的时候可能只是想让某个后缀能跑PHP，没想过这行指令会打开一扇门。安全这东西，往往就输在这些不起眼的细节上。