PHP服务器安全审计：90%高危漏洞藏于配置末行

　　去年8月，小孟在门户干了4年频道编辑，那会儿专题页改版被产品推翻三次，上线前夜又改回初版——我连着盯了三晚发布后台的PHP错误日志，就为了搞清为啥每次切模板都报500，而错误堆栈里第七行永远指向 /etc/php/7.4/apache2/php.ini。不是开头，不是中间，是末行。最后一行。

　　那天下午五点十七分，机房空调嘶嘶响，像没关严的气阀，我端着半凉的黄焖鸡米饭蹲在测试服务器前——外卖盒盖子掀开还浮着层油，筷子搁在盒沿上斜着。运维老张探头进来问“ini改好了没”，我点头，他转身时把门带得哐一声，震得机柜顶上那瓶快见底的红牛晃了两下。我原以为是open_basedir路径写错了，结果grep了三遍，发现是末行多敲了个空格，后面跟了个未闭合的引号：`extension=gd.so `（注意那个空格）——就这玩意儿，让整个Apache加载模块时卡死在register_ini_entries阶段，但报错不显，只返回空白响应。你查access_log有200，查error_log却干净得像擦过黑板。

　　我敢打包票，这种事绝不止我们一家。上周帮财经频道查他们转载页的XSS泄露，顺手扫了台测试服，php.ini末行赫然写着`expose_php = On`——底下还压着一行注释：`# 这行别删，产品经理说要留着看版本号`。呵。暴露PHP版本算什么？真正的刀在倒数第二行：`cgi.fix_pathinfo=1`，没注释，没缩进，就孤零零杵在文件最底下，像根没拔干净的钉子。这个配置一开，任意上传的.png后面接个/.php，就能绕过所有上传白名单，直接当脚本执行。你说谁会去翻ini文件最后三行？运维交接文档写的是“已加固”，没写“加固完随手在末尾加了句debug_print_r($_SERVER)”。

　　小孟后来把稿子发给我看，标题叫《转载授权扯皮，对方编辑微信已读不回》，底下配图是对方后台的编辑器截图，左下角时间水印显示是上季度末凌晨两点零三分。我盯着那张图看了十八秒，突然点开自己本地备份的phpinfo()快照——一样，他们生产环境的php.ini末行是`zend_extension=/usr/lib/php/20190902/xdebug.so`，而前面二十行全在调优opcache，唯独这一行，孤零零挂在⭐️⭐️⭐️⭐️连分号都没打。Xdebug在生产环境开着？还挂最末尾？它不像其他扩展那样require或extension=xxx规整排列，它偏要躺平——就像人加班到凌晨三点，脑子已经停转，手指却还条件反射地往文件最底下敲一行无关紧要的注释。

　　桌上的黄焖鸡米饭凉透了，汤凝成浅褐色油膜。我叉起一块土豆，嚼着嚼着想起来：上次线上MySQL被拖库，溯源发现不是SQL注入，是PHP-FPM进程用了www-data用户跑，而/etc/php/7.4/fpm/pool.d/www.conf里末行写着`php_admin_value[disable_functions] = `——空值。空值！disable_functions后面什么都没填，等于彻底放开system、exec、shell_exec……可这个配置项明明在第二百三十四行就该填好，偏偏他们交接时copy-paste，漏掉了前二百三十三行，只粘了最后一行空壳。我问过当时接手的实习生，他说“看前面有内容，以为末行是默认值”。优胜劣汰？对。不是配置越靠前越重要，是越靠后越没人看，越容易活下来，越能杀人。90%高危漏洞藏于配置末行——不是统计出来的，是淘汰率刷出来的。活下来的，都是没被任何人 eyeball 过的。

文章配图，仅供参考

　　所以现在我养成个毛病：审计PHP服务器，第一件事不是扫端口，不是看WAF日志，是ssh进去，cd /etc/php//，然后for i in $(ls); do tail -n 3 $i//.ini | head -n 1; done ——就看末行。有时候末行是空白，有时候是中文乱码，有一次还是半截base64解不开的字符串。但只要你见过三次以上末行藏雷，你就不会再信“已加固”这三个字。小孟今天早上发来一条消息：“稿子又被SEO改了，作者说要告我们。”我回：“先别急，我帮你看看他们站的phpinfo里末行写啥。”

　　对了，窗外现在还在下雨，雨刮器节奏不对，左边那根卡在四十五度角，一下，停顿，两下，停顿，第三下才甩下去。机柜嗡嗡声混着雨声，听久了像有人在用指甲刮黑板边缘。我原以为这是硬件问题，结果发现是UPS电池报警灯在闪——但没人管，因为报警声太像空调外机共振。这种事儿，真没法一句两句说完。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!