文件上传漏洞与phpcms漏洞安全分析

目录

1. 文件上传漏洞简介

2. 文件上传漏洞的危害

3. 文件上传漏洞的触发条件

1. 文件必须能被服务器解析执行

2. 上传目录必须支持代码执行

3. 需要能访问上传的文件

4. 例外情况：非脚本文件也可能被执行

4. 常见的攻击手法

4.1 直接上传恶意文件

4.2 文件扩展名绕过

4.3 解析漏洞利用

5. 文件上传漏洞的防御措施

5.1 文件类型检查

5.2 上传路径与访问控制

5.3 服务器配置安全

6.phpcms文件上传漏洞安全分析

6.1.前言

6.2.漏洞情况

第一关：初代 PHPCMS 头像上传漏洞

第二关：FineCMS 的补丁与再次绕过(竞争条件漏洞)

​编辑

第三关：利用随机数生成目录名漏洞

第四关：新补丁

正确的修复方式

结论

---

1. 文件上传漏洞简介

文件上传漏洞是一种常见的 Web 安全漏洞，攻击者可以通过该漏洞上传恶意文件，如 WebShell、木马或其他恶意代码脚本，以实现远程控制服务器、窃取数据或发起进一步攻击。这类漏洞通常源于 Web 应用在文件上传功能的安全校验不当，例如缺乏文件类型验证、文件存储位置不合理或服务器解析机制存在漏洞。

2. 文件上传漏洞的危害

文件上传漏洞可能导致以下安全风险：

1. 代码执行：攻击者上传 Web 脚本语言文件（如 .php、.jsp、.asp），服务器解析执行后，黑客可直接控制服务器。

2. 恶意文件传播：上传病毒或木马文件，诱骗用户或管理员下载执行，导致感染。

3. 策略文件篡改：上传 crossdomain.xml 等策略文件，控制 Flash 或其他前端组件的跨域行为，可能导致 CSRF、XSS 等安全问题。

4. 钓鱼与欺诈：上传伪造的钓鱼图片，或利用图片解析漏洞，在部分浏览器环境下执行恶意 JavaScript 代码。

5. 服务器程序溢出：利用某些应用的文件解析逻辑漏洞，如图片处理模块缺陷，实现远程代码执行（RCE）。

6. 本地文件包含（LFI）利用：上传包含恶意 PHP 代码的文本文件，再通过 LFI 漏洞执行该脚本，从而实现服务器控制。

3. 文件上传漏洞的触发条件

要成功利用文件上传漏洞，攻击者上传的后门文件需要满足以下关键条件：

1. 文件必须能被服务器解析执行

攻击者上传的恶意文件必须符合服务器的运行环境。例如：

• 如果服务器运行的是 PHP 环境，则攻击者需要上传 .php 文件。
• 如果服务器运行的是 JSP 环境，则需要上传 .jsp 文件。
• 如果服务器运行的是 ASP.NET，则 .aspx 文件可能有效。

示例：
如果目标服务器只支持 PHP，而攻击者上传的是 Java Webshell（.jsp），即使上传成功，服务器也无法解析执行，攻击仍然无效。

2. 上传目录必须支持代码执行

即使上传了可执行脚本，文件存储的路径也必须是可执行目录，否则服务器不会解析代码。

• 可执行目录： 服务器会解析 .php，jsp，asp 等脚本，并执行其中的代码。
• 非可执行目录： 服务器会将脚本文件当作普通文本处理，无法运行恶意代码。

示例：
如果 Web 应用将上传的文件存放在 /uploads/ 目录，并且 Nginx 或 Apache 已经配置禁止该目录执行脚本，那么即使攻击者上传了 shell.php，服务器也不会解析并执行其中的代码，攻击失败。

3. 需要能访问上传的文件

通常，上传文件成功后，服务器会返回上传文件的访问地址。如果攻击者无法访问这个地址，文件上传漏洞也无法被利用。

示例：

• 如果服务器存储路径是 /var/www/uploads/，但外部无法访问该目录，即使攻击者上传了 Webshell 也无法触发它。
• 如果文件上传成功，但服务器未返回文件访问路径，攻击者无法得知上传文件存放在哪里，除非能通过其他漏洞（如目录遍历）找到它。

4. 例外情况：非脚本文件也可能被执行

某些情况下，即使上传的不是脚本文件，也可能被服务器错误解析，从而执行恶意代码。例如：

• 图片马（图片木马）：攻击者上传一张 .jpg 或 .png 图片，但图片的元数据中隐藏了 PHP 代码。如果服务器存在解析漏洞，可能会执行隐藏代码。
• 配置错误的 Web 服务器：某些中间件（如 Apache、Nginx、IIS）可能存在解析漏洞，使非 .php 文件也会被当作 PHP 代码解析。

4. 常见的攻击手法

4.1 直接上传恶意文件

攻击者利用未做任何安全限制的上传接口，直接上传如 .php、.jsp、.asp 等可执行脚本。

4.2 文件扩展名绕过

攻击者使用以下方式绕过服务器对文件后缀的限制：

• 双重扩展名（如 shell.php.jpg）
• 大小写绕过（如 SHELL.PHP）
• 空格或特殊字符绕过（如 shell.php. ）
• MIME 类型伪造（通过修改 Content-Type 伪造合法文件）

4.3 解析漏洞利用

不同 Web 服务器对文件解析方式不同，可能导致绕过扩展名检查。例如：

• Apache 服务器：支持 .htaccess 配置文件，攻击者可以上传 .htaccess 文件修改解析规则。
• IIS 服务器：shell.asp;.jpg 可能仍会被解析为 .asp。
• Nginx 解析漏洞：某些版本可能会错误解析 .php/ 文件。

5. 文件上传漏洞的防御措施

5.1 文件类型检查

• 采用白名单机制，仅允许上传安全的文件类型，如 .jpg、.png、.pdf 等。

• 验证文件扩展名，避免使用双重扩展名（如 shell.php.jpg）绕过检测。

• 检查 MIME 类型，防止攻击者伪造文件类型。

• 使用文件内容分析工具（如 fileinfo）检查文件实际类型。

5.2 上传路径与访问控制

• 存储文件时重命名，避免使用用户自定义的文件名。

• 限制上传目录的权限，确保其不可执行（例如通过 Nginx 配置 disable_php ）。

• 采用分离存储策略，将上传文件存放在与 Web 目录隔离的存储服务器上。

• 避免返回完整的文件路径，降低攻击者利用漏洞的可能性。

5.3 服务器配置安全

• 禁止执行上传目录中的脚本，如 Apache 配置 .htaccess 限制 PHP 解析。

• 禁用危险函数，如 eval()、exec()，防止远程代码执行。

• 开启 WAF（Web 应用防火墙），检测并拦截恶意上传行为。

• 定期扫描上传文件，发现并删除可疑文件。

6.phpcms文件上传漏洞安全分析

6.1.前言

PHPCMS 曾经是国内流行的 CMS 之一，但因安全漏洞频发，给广大站点带来了严重的安全隐患。其中，头像上传漏洞尤为经典，不仅影响 PHPCMS 本身，还波及了大量借鉴其代码的 CMS，如 FineCMS。

6.2.漏洞情况

第一关：初代 PHPCMS 头像上传漏洞

PHPCMS 头像上传功能的逻辑如下：

1. 用户上传 ZIP 压缩包。

2. 服务器解压 ZIP，并删除非 JPG 文件。

漏洞代码片段：

漏洞点分析

• 解压后仅删除 ZIP 根目录中的非法文件，但未递归删除文件夹中的非法文件。

复现步骤如下：

1. 攻击者可上传 ZIP 包，其中包含 test 目录，并在其中放置 web.php，绕过删除机制。

第二关：FineCMS 的补丁与再次绕过(竞争条件漏洞)

FineCMS 修复代码：

利用时间差上传 ZIP 文件，其中包含如下代码：

<?php fputs(fopen('../../../../../shell.php','w'),'<?php phpinfo();eval($_POST[a]);?>');?>

在服务器解压 ZIP 并执行删除操作的瞬间，攻击者访问 webshell，实现 Getshell。

复现步骤如下：利用burp抓包，然后通过不停发包与刷新，访问php文件，让他在上级或者其他级目录生成恶意代码

第三关：利用随机数生成目录名漏洞

为了防止竞争条件攻击，开发者修改了代码，使上传的文件存放在随机命名的目录中。然而，新机制未能正确处理解压失败的情况，导致 Webshell 仍然可能被上传。

复现步骤如下：

1. 构造一个解压失败的压缩包。
2. 让 PHPCMS 处理解压失败，但部分文件仍然被释放到 Web 目录。
3. 由于目录删除机制缺陷，Webshell 仍然得以保留。

如何构造解压失败的压缩包

第四关：新补丁

• 头像文件解压至随机命名的目录。

• 发生错误时，立即删除临时目录。

代码示例：

绕过方法：路径穿越攻击（Directory Traversal）

• 构造 ZIP 文件，修改其内部文件名，如 ../../../index.php。

• 利用 Notepad++ 修改 ZIP 内部文件路径，上传后覆盖网站根目录的 index.php，实现 Webshell。

正确的修复方式

以上漏洞的根本问题在于：

1. 不应直接在 Web 目录下解压用户上传的文件。

2. 应使用白名单方式限制解压文件。

3. 避免使用 Zip 方式上传头像，改用前端处理。

安全修复方案：

• 将 ZIP 文件解压到临时目录（如 /tmp）。

• 仅提取合法的 JPG 文件，其他文件一律忽略。

• 对解压缩的文件进行严格 MIME 类型检测。

• 采用白名单方式，避免黑名单的局限性。

结论

PHPCMS 头像上传漏洞的演变历程，展现了补丁打补丁的错误思路。正确的修复方法应从设计上避免问题，而不是简单地对抗攻击者的新手法。开发者应深刻理解文件上传的安全风险，避免重蹈覆辙。

仅仅是技术分享，不要再审核卡我啦