YCCMS v3.4 代码审计教学文档<\/strong><\/h2>
文档概述<\/strong><\/h3>
本教学文档旨在通过剖析YCCMS（一个内容管理系统）v3.4版本的源代码，系统地讲解代码审计的流程、常见漏洞的挖掘方法、漏洞原理及修复方案。YCCMS是一个典型的MVC（Model-View-Controller）架构的PHP应用程序，非常适合用于学习PHP代码审计。<\/p>
审计目标：<\/strong> YCCMS v3.4
核心发现：<\/strong> 存在未授权访问、任意文件删除、文件上传绕过、代码执行等高危漏洞。<\/p>

一、基础信息收集与分析<\/strong><\/h3>
在开始深入审计前，需要对目标应用有一个基本的了解。<\/p>

URL结构分析<\/strong>：<\/p>

通过观察后台管理功能的URL，可以发现其采用a<\/code>和m<\/code>参数分别指代控制器（Controller）和方法（Method）。<\/li>
示例<\/strong>： http:\/\/127.0.0.1\/admin\/?a=article&m=add<\/code> a=article<\/code> 表示调用 ArticleAction<\/code> 控制器。<\/li> m=add<\/code> 表示调用该控制器下的 add()<\/code> 方法。<\/li> <\/ul> <\/li> 对应的文件路径为：\/controller\/ArticleAction.class.php<\/code>。<\/li> <\/ul> <\/li> 框架识别<\/strong>：<\/p> 尝试搜索 version<\/code>、thinkphp<\/code> 等关键字，未发现使用已知主流框架（如ThinkPHP）的痕迹。结论：这是一个原生PHP编写的、自研的MVC框架应用。<\/li> <\/ul> <\/li> <\/ol> 二、漏洞审计详解<\/strong><\/h3> 漏洞1：未授权访问导致的管理员密码篡改<\/strong><\/h4> 漏洞类型<\/strong>：访问控制缺失<\/p> <\/li> 危险等级<\/strong>：高危<\/p> <\/li> 漏洞位置<\/strong>： admin\/?a=admin&m=update<\/code><\/p> <\/li> 涉及文件<\/strong>：<\/p> \/controller\/AdminAction.class.php<\/code> 中的 update()<\/code> 方法。<\/li> \/model\/AdminModel.class.php<\/code> 中的 editAdmin()<\/code> 方法。<\/li> <\/ul> <\/li> 漏洞原理<\/strong>：<\/p> 在AdminAction.class.php<\/code>的update()<\/code>方法中，直接调用了$this->_model->editAdmin()<\/code>来修改管理员信息。<\/li> 整个调用链没有任何的会话验证或权限检查<\/strong>（例如，没有检查用户是否已登录、是否是管理员）。<\/li> 因此，攻击者无需登录，即可直接通过访问该URL并传入新用户名和密码的参数，篡改任意管理员账号的密码。<\/li> <\/ol> <\/li> 审计技巧<\/strong>：<\/p> 入口扫描<\/strong>：重点关注所有\/admin\/?a=...<\/code>的入口点。<\/li> 权限校验缺失<\/strong>：检查每个控制器方法的首部是否存在统一的权限验证代码（如$this->checkLogin();<\/code>）。在本案例中，整个应用缺乏这种全局或基类的控制。<\/li> <\/ul> <\/li> 举一反三<\/strong>：通过此漏洞可以发现，整个后台的权限校验体系是缺失的<\/strong>。审计员应系统性地检查所有后台功能（如文章删除a=article&m=delete<\/code>），很可能都存在类似的未授权访问问题。<\/p> <\/li> <\/ul> 漏洞2：未授权任意文件删除<\/strong><\/h4> 漏洞类型<\/strong>：权限绕过、路径遍历<\/p> <\/li> 危险等级<\/strong>：高危<\/p> <\/li> 漏洞位置<\/strong>： admin\/?a=pic&m=delall<\/code><\/p> <\/li> 涉及文件<\/strong>： \/controller\/PicAction.class.php<\/code> 中的 delall()<\/code> 方法。<\/p> <\/li> 漏洞原理<\/strong>：<\/p> 该方法用于批量删除图片。它接收一个名为pid[]<\/code>的数组参数，数组中包含要删除的图片文件名。<\/li> 代码直接将文件名与基础路径ROOT_PATH.'\/uploads\/'<\/code>进行拼接，形成完整的文件路径 $_filePath<\/code>。<\/li> 随后直接调用 unlink($_filePath)<\/code> 进行删除，未对文件名进行任何过滤<\/strong>。<\/li> 由于该功能同样缺乏权限校验<\/strong>，攻击者可以构造特殊的文件名进行路径遍历，删除服务器上的任意文件。<\/li> <\/ol> <\/li> 攻击复现（PoC）<\/strong>：<\/p> URL<\/strong>: http:\/\/127.0.0.1\/admin\/?a=pic&m=delall<\/code><\/li> POST数据<\/strong>: pid[0]=..\/..\/..\/config\/database.config.php chkall=on send=删除选中图片 <\/code><\/pre> <\/li> 此Payload可以删除网站根目录下config<\/code>文件夹中的数据库配置文件，导致网站瘫痪。<\/li> <\/ul> <\/li> <\/ul> 漏洞3\/4：文件上传漏洞（两处）<\/strong><\/h4> 这两处漏洞原理相似，都是由于对上传文件的MIME类型验证存在缺陷。<\/p> 漏洞类型<\/strong>：文件上传绕过<\/p> <\/li> 危险等级<\/strong>：高危<\/p> <\/li> 漏洞位置1<\/strong>： admin\/?a=call&m=upfile&type=content<\/code> (最终调用 upLoad<\/code> 方法)<\/p> <\/li> 漏洞位置2<\/strong>： admin\/?a=call&m=xhUp&type=content<\/code><\/p> <\/li> 涉及文件<\/strong>： \/controller\/CallAction.class.php<\/code> 中的 upLoad()<\/code> 和 xhUp()<\/code> 方法。<\/p> <\/li> 漏洞原理<\/strong>：<\/p> 代码在验证文件类型时，依赖于 $_FILES['pic']['type']<\/code> 的值。<\/li> $_FILES['pic']['type']<\/code> 是由浏览器端提交的，可以被攻击者随意篡改<\/strong>。<\/li> 验证逻辑 in_array($this->type, $this->typeArr)<\/code> 只是简单判断这个值是否在允许的类型数组中（如 image\/png<\/code>）。<\/li> 攻击者只需上传一个恶意文件（如.php<\/code>后缀），然后在Burp Suite等工具中抓包，将 Content-Type<\/code> 头部修改为 image\/png<\/code>，即可绕过检查，成功上传Webshell。<\/li> <\/ol> <\/li> 修复方案对比<\/strong>：<\/p> 错误方式<\/strong>：信任客户端提交的MIME类型。<\/li> 正确方式<\/strong>：使用服务器端验证，例如检查文件的真实类型（使用 finfo_file(FILEINFO_MIME_TYPE)<\/code> 函数）和文件扩展名白名单机制。<\/li> <\/ul> <\/li> <\/ul> 漏洞5：代码执行漏洞<\/strong><\/h4> 漏洞类型<\/strong>：代码注入<\/p> <\/li> 危险等级<\/strong>：严重<\/p> <\/li> 漏洞位置<\/strong>：多个入口文件，如 \/admin\/index.php<\/code>, \/search\/index.php<\/code>, \/config\/count.php<\/code>。<\/p> <\/li> 涉及文件<\/strong>： \/public\/class\/Factory.class.php<\/code>。<\/p> <\/li> 漏洞原理<\/strong>：<\/p> Factory.class.php<\/code> 是程序的调度核心。它通过 $_a = self::getA();<\/code> 获取URL中的 a<\/code> 参数。<\/li> 然后使用 file_exists()<\/code> 检查对应的控制器文件是否存在。<\/li> 最后，使用 eval()<\/code> 函数动态实例化控制器类：eval('self::$_obj = new '.ucfirst($_a).'Action();');<\/code><\/li> 这里的 $_a<\/code> 参数未经任何过滤就直接拼接进了eval语句<\/strong>，造成了代码注入漏洞。<\/li> <\/ol> <\/li> 漏洞利用详解<\/strong>：<\/p> 目标<\/strong>：闭合 new <\/code> 语句，并注入恶意代码。<\/li> Payload构造<\/strong>： a=Factory();phpinfo();\/\/..\/<\/code><\/li> 代码解释<\/strong>： ucfirst($_a)<\/code> 将 a<\/code> 的值变为 Factory();phpinfo();\/\/..\/<\/code>。<\/li> 拼接后的eval语句为：self::$_obj = new Factory();phpinfo();\/\/..\/Action();<\/code><\/li> \/\/<\/code> 在PHP中是注释符，其后的 ..\/Action();<\/code> 会被注释掉。<\/li> 最终执行的代码是： self<\/span>::<\/span>$_obj =<\/span> new<\/span> Factory<\/span>(); \/\/ 实例化Factory类（如果该类存在且可实例化） <\/span><\/span><\/span><\/span>phpinfo<\/span>(); \/\/ 执行phpinfo()函数 <\/span><\/span><\/span><\/code><\/pre><\/li> <\/ol> <\/li> 利用结果<\/strong>：访问 http:\/\/127.0.0.1\/admin\/index.php?a=Factory();system('calc');\/\/..\/<\/code> 甚至可以在服务器上弹出计算器（如果服务器是Windows系统且权限允许），证明漏洞危害极大。<\/li> <\/ul> <\/li> 关键技巧<\/strong>：<\/p> 利用 file_exists()<\/code> 在Windows下的路径解析特性（\/\/<\/code> 被当作 \<\/code>，..<\/code> 用于目录遍历），使检查能够通过，指向一个实际存在的文件（如..\/Action.class.php<\/code>），从而绕过 file_exists()<\/code> 的检查。<\/li> <\/ul> <\/li> <\/ul> 三、漏洞修复方案总结<\/strong><\/h3> 针对以上发现的漏洞，提出以下系统性的修复建议：<\/p> 强化权限校验体系<\/strong>：<\/p> 建立一个基类控制器（如BaseAction.class.php<\/code>），在其构造函数中调用统一的权限验证方法（如checkPermission()<\/code>）。<\/li> 让所有后台的控制器都继承自这个基类，确保每个后台操作在执行前都经过了权限验证。<\/li> <\/ul> <\/li> 安全的文件删除<\/strong>：<\/p> 不要直接使用用户输入拼接路径<\/strong>。建议通过加密的ID映射到具体的文件路径，或对文件名进行严格的白名单过滤（只允许字母、数字、短横线、下划线等）。<\/li> 在删除前，再次验证目标文件是否位于允许操作的目录内（如\/uploads\/<\/code>）。<\/li> <\/ul> <\/li> 加固文件上传功能<\/strong>：<\/p> 采用白名单机制<\/strong>：只允许指定的、安全的文件扩展名（如.jpg<\/code>, .png<\/code>, .gif<\/code>）。<\/li> 服务器端验证<\/strong>：使用 finfo_file()<\/code> 函数检测文件的真实MIME类型，绝不信任 $_FILES['file']['type']<\/code>。<\/li> 重命名文件<\/strong>：将上传的文件重命名为随机字符串（如UUID），并保留原有扩展名，防止文件名注入和恶意文件被执行。<\/li> 隔离存储<\/strong>：将上传的文件存储在Web根目录之外，通过专门的脚本来访问，避免直接执行。<\/li> <\/ul> <\/li> 杜绝代码注入<\/strong>：<\/p> 绝对禁止使用eval()<\/code><\/strong>：尤其是在动态实例化类的地方。应使用安全的反射机制或预先定义好的映射数组来替代。<\/li> 示例（安全方式）<\/strong>： $allowedControllers =<\/span> ['article'<\/span>, 'admin'<\/span>, 'pic'<\/span>, ...<\/span>]; <\/span><\/span>$controllerName =<\/span> $_GET['a'<\/span>]; <\/span><\/span>if<\/span> (!<\/span>in_array<\/span>($controllerName, $allowedControllers)) { <\/span><\/span> die<\/span>('Invalid controller'<\/span>); <\/span><\/span>} <\/span><\/span>$className =<\/span> ucfirst<\/span>($controllerName) .<\/span> 'Action'<\/span>; <\/span><\/span>self<\/span>::<\/span>$_obj =<\/span> new<\/span> $className(); \/\/ 安全的方式，无需eval <\/span><\/span><\/span><\/code><\/pre><\/li> <\/ul> <\/li> <\/ol> 四、代码审计方法论总结<\/strong><\/h3> 通过本次YCCMS的审计，可以总结出以下方法论：<\/p> 信息收集<\/strong>：理解应用的URL路由、目录结构和技术栈。<\/li> 入口点定位<\/strong>：梳理所有用户可控的输入点（GET\/POST参数、Cookie、HTTP头）。<\/li> 敏感函数追踪<\/strong>：全局搜索 unlink<\/code>（文件删除）、move_uploaded_file<\/code>（文件上传）、eval<\/code>\/assert<\/code>（代码执行）、system<\/code>\/exec<\/code>（命令执行）、SQL查询函数等，逆向追踪用户输入是否能够不受控制地到达这些函数。<\/li> 权限校验审查<\/strong>：系统性检查关键功能是否存在权限校验，是否存在越权访问（水平越权、垂直越权）。<\/li> 逻辑漏洞挖掘<\/strong>：关注业务流程，如验证码绕过、密码修改、订单支付等环节是否存在逻辑缺陷。<\/li> <\/ol> 希望这份详尽的教学文档能帮助你深入理解代码审计的思维和技巧。<\/p>