tp5漏洞
ThinkPHP 5 的漏洞远程命令执行漏洞，说白了就是漏洞一条 URL 就能让攻击者在服务器上跑任意代码。2018 年底曝出来的漏洞那个 CVE-2018-20062，影响面大到什么程度？漏洞国内大量中小企业的后台系统、API 网关、漏洞甚至一些政务平台都在用 TP5 做底层框架，漏洞补丁还没推完，漏洞批量扫描器就已经全网跑了。漏洞
漏洞的漏洞根子在 Request 类对 method 参数的解析上。TP5 允许通过 ?漏洞s=index/\think\Request/input 这类路由直接调用框架内部方法，而 input 方法又没对传入的漏洞 filter 参数做足够严格的校验。攻击者构造一条类似这样的漏洞请求：
POST /index.php?s=index/\think\Request/input Content-Type: application/x-www-form-urlencoded filter[]=system&data=whoami服务器就直接把 whoami 的结果吐回来了。没有登录验证，漏洞没有权限检查，漏洞一个 HTTP 请求搞定。漏洞我第一次在测试环境复现的时候，看到回显里跳出 www-data，后背确实凉了一下——这意味着任何能访问到站点的 IP，都等同于拿到了一个低权限 shell。
更麻烦的是利用链不止一条。除了 Request::input，还有通过 think\app 的 invokeFunction 反射调用任意函数的路子。攻击面比官方最初公告的要宽。当时圈子里有人做了统计，ZoomEye 上暴露的 TP5 站点大概有十几万个，其中能直接打通的保守估计在三成以上。这个比例很吓人，因为很多站点部署在云主机上，安全组只开了 80 和 443，运维觉得“只暴露 Web 端口就安全了”，结果框架层面直接失守。
为什么 TP5 会出现这种设计？跟它早期的路由理念有关。TP 为了追求“简洁灵活”，把很多内部方法暴露成了可通过 URL 触达的入口。开发者图方便，框架图优雅，安全边界就被模糊掉了。对比一下 Laravel，同样有反射调用，但默认路由不会把 Request 类的方法直接映射出去。TP5 这个口子开得太大，等于把框架内核的钥匙挂在了门把手上。
修复方案其实不复杂。官方在 5.0.24 和 5.1.31 版本里加了 method 白名单校验，同时建议在入口文件里加上对 s 参数的过滤。但问题在于，大量项目锁死在旧版本上——有些是因为改了核心代码不敢升级，有些是外包做完就没人维护了。我见过一个客户，服务器上跑的还是 5.0.10，问他们为什么不升，回答是“升级怕把业务搞挂”。这种心态在国内中小项目里太普遍了。
临时缓解手段也有。在 Nginx 里加一条规则，拦截 URL 中包含 \think\Request 或 invokeFunction 的请求，能挡住大部分自动化扫描。但手工构造的 payload 可以编码绕过，所以这只是权宜之计。真正靠谱的还是升级框架版本，或者至少把 app_debug 关掉、app_trace 关掉，减少信息泄露。不过说实话，关了 debug 也挡不住 RCE，只是让攻击者少了一些辅助信息。
这件事给我最大的感受是：国内 PHP 生态里，框架安全更新太被动了。TP5 漏洞爆发的时候，很多团队的第一反应是“等官方出补丁”，而不是“先下线或加 WAF 规则”。等补丁出来了，又拖着不升。攻击者比运维勤快，这是常态。所以如果你手上还有 TP5 的项目，别管业务忙不忙，先把版本号查一遍。5.0.24 以下的，5.1.31 以下的，该升就升，该加规则就加规则。别等服务器被挖矿了才想起来看日志。