- ```html
2017年冬天,编辑一个做企业站的器漏朋友半夜给我打电话,说网站被挂马了。编辑我登上服务器一看,器漏根目录多出个
upload_json.php,编辑内容就一行——接收POST参数,器漏直接move_uploaded_file。编辑这文件不是器漏他写的。翻日志,编辑攻击者从/kindeditor/php/file_manager_json.php进来的器漏,路径明晃晃挂在URL里,编辑连伪装都懒得做。器漏KindEditor这个编辑器,编辑国内做站的器漏人太熟了。开源、编辑轻量、中文文档齐全,2010年前后几乎成了CMS标配。问题就出在它“太方便”上——为了方便演示,官方包里的
php/upload_json.php和php/file_manager_json.php默认就带着,而且默认配置几乎不设防。你下载解压,往服务器一扔,路径都没改,攻击者用扫描器跑一遍/kindeditor/php/upload_json.php,就能直接往你服务器写文件。漏洞的核心不在编辑器本身,在那些“示例文件”。
upload_json.php里有个$save_path变量,默认是../../attached/,但很多开发者直接把它改成网站根目录,或者更糟——保留默认相对路径却不做任何后缀白名单。攻击者上传一个shell.php,Content-Type改成image/jpeg,后端只检查了$_FILES['imgFile']['type'],这玩意儿客户端随便伪造。文件落地,路径可猜,直接访问,服务器就姓了别人的姓。我后来专门扫过一批站。用FOFA搜
kindeditor/php/upload_json.php,结果里至少三成页面直接返回{ "error":0,"url":"..."},意思是接口活着,而且没鉴权。更离谱的是有些站把编辑器目录放在/static/kindeditor/下,上传目录也设在同层,攻击者传完马,URL就是/static/kindeditor/attached/shell.php,连目录遍历都省了。有人觉得这事怪KindEditor官方。官方其实在4.1.5之后加了
$php_upload_max_size和扩展名检查,但默认配置文件upload_json.php里那段in_array($file_ext, $ext_arr)的判断,很多老版本压根没有。更麻烦的是,大量CMS把KindEditor二次打包,改了路径、改了变量名,却忘了删示例文件。你搜“KindEditor 漏洞”,出来的文章十篇有八篇在讲XSS,真正要命的文件上传反而被一笔带过。修复这事其实不复杂。第一,生产环境直接删掉
php/、asp/、jsp/这些示例目录,一个不留。第二,如果非要用自带上传接口,把upload_json.php里的$ext_arr改成白名单,只留jpg|png|gif,并且用getimagesize()验证真实图片类型。第三,上传目录设成不可执行——Nginx里加location ~* /attached/.*\.(php|php5|phtml)$ { deny all; },Apache用.htaccess关掉php_flag engine off。这三步做完,99%的脚本小子就进不来了。但现实是,我去年帮一个客户做应急,发现他们用的还是KindEditor 4.1.4,上传接口没鉴权,目录可执行。问运维,运维说“这编辑器是外包公司五年前装的,没人敢动”。你看,漏洞从来不只是技术问题。一个2013年就被公开的利用方式,到2024年还在被批量扫描,说明什么?说明大量站点的技术债根本没还,而攻击者比运维更勤快。
最后说个细节。KindEditor的GitHub仓库最后一次commit停在2021年,作者早就不维护了。但国内各种下载站还在推“KindEditor最新版”,压缩包里照样带着
``` 顶: 784踩: 6php/upload_json.php。你下下来直接用,等于在服务器上开了个后门。别问我是怎么知道的——我帮人擦过太多次屁股了。






评论专区