Appcms 作为一款曾在网站开发领域有一定应用的内容管理系统，其代码安全性直接关系到基于该系统搭建网站的运营安全。通过对 Appcms 源码的深入审计，我们发现了多处存在安全隐患的漏洞，这些漏洞若被恶意攻击者利用，可能导致服务器权限被窃取、敏感数据泄露等严重后果。本文将对审计过程中发现的典型漏洞进行详细分析，并提供对应的实战验证步骤与防御建议。

一、任意文件包含漏洞审计（前台 RCE）

（一）漏洞原理与位置审计

在 Appcms 的 index.php 文件中，大约第 202 行存在路径拼接逻辑，审计发现 $tpl 参数可由用户直接控制，且系统未对该参数进行任何有效的路径过滤与安全校验。这就使得攻击者能够构造特殊的参数值，将任意文件包含到 /template/default/ 文件夹下的页面渲染流程中。

不过，该漏洞的利用存在一个关键限制：系统会在包含文件时自动拼接 .php 后缀。例如，若攻击者上传了一个名为 xxxxx.jpg 的恶意文件，直接包含会因文件后缀不匹配导致模板查找失败。

接下来我们可以有两种办法

1. 包含中间件的日志（这套cms好像没有自己的日志）

2. 找前台可上传的点，上传我们的文件然后利用文件包含进行引入

我这里尝试了第二种，因为在实战过程中第一种的路径又需要信息搜集不是很稳，如果我们能有cms的前台上传点的话那么就很稳了

这里我翻了翻源码发现在upload文件夹下有两个文件

直接访问第一个文件会发现有权限校验。

访问第二个文件发现是一个上传样式。

图片上传之后发现没反应，f12查看源码，发现会将请求发送到/upload/upload_file.php?params=&v=dBJhuBrKulYUJ8wNxlliKrclH接口

这不直接本地梭哈一下

本地构造上传文件,点击上传，美滋滋文件上传成功了

<form id="form1" enctype="multipart/form-data" method="post" action="http://192.168.1.13//upload/upload_file.php?params=&v=3udxH=Y=3WK9P0tRR2pLEBBVe">
<input type="file" name="Filedata">
<input type="submit" value="Upload">
</form>

同时在url中返回了重新命名的文件名

url解码一下

然后回到我们的index文件，直接包含+截断

美滋滋啊 真不戳

既然发现了接口未授权我们就去看一下好了

文件/upload/upload_file.php

发现这里源码是根据get和v参数接受到的参数进行鉴权的，看来是大意了呀，还是得从session中进行鉴权。

那么再去看upload_form.php为啥会显示get和v参数的值

发现这里35行直接获取了，其实主要是这个文件没有做好权限的校验，导致我们能获取get和v从而上传文件。

（三）漏洞根源审计分析

1. 权限校验缺失：upload_form.php 文件未对访问者身份进行严格的权限校验，导致攻击者可直接获取上传所需的 get 和 v 参数，进而绕过鉴权发起文件上传请求。
2. 参数过滤不足：index.php 中的 $tpl 参数未经过路径规范化、白名单过滤等处理，直接用于路径拼接，给任意文件包含漏洞的产生留下了可乘之机。

二、部分 SSRF 与文件读取漏洞审计

（一）漏洞原理与位置审计

该漏洞存在于 pic.php 文件中，系统本意是通过该文件实现图片相关的处理功能，但审计发现参数处理逻辑上存在安全缺陷，导致攻击者可利用该漏洞实现部分文件读取与服务器端请求伪造（SSRF）。

系统对传入的参数会先进行 Base64 解码，然后通过 . 拆分 URL 并判断最后一个 . 后的后缀是否在允许的数组中，同时会检查参数中是否包含 php 字符串以禁止读取 PHP 文件。不过，这些防护措施存在明显漏洞：攻击者可通过构造如 ?q=1.jpg 这样的参数绕过后缀检查，且由于 Base64 解码过程中不会额外进行 URL 解码，URL 编码绕过方式在此处失效，但仍可通过其他方式利用漏洞。

（二）漏洞利用场景审计

1.部分文件读取

这里读取的是index.php因为访问目录的时候默认访问的是 index文件，所以我们可以构造

http://localhost/?q=1.jpg进行读取主页的源码，或配置文件等

2.部分ssrf

同样由于php的限制我们只能访问 index这样的页面

http://localhost/?q=1.jpg

发现在第17行的时候，host头可控，正常情况下可以利用%0a%0d 进行CRLF攻击

但是header函数自4.4之后就增加了对host头攻击的保护 ，所以这里是不会存在CRLF注入等

三、SQL 注入漏洞审计分析（未复现）

在对 comment.php 文件的审计过程中，我们重点检查了评论功能是否存在 SQL 注入漏洞，最终判断该文件在当前版本中不存在可利用的 SQL 注入风险，具体原因如下：

首先$page['post']接受的是post接受到的数据，按照如下格式存储在page['post']中

继续往下看 ，发现对传入对参数都进行了html实体化处理

这样我们无法通过闭合前面的特殊符号来使得我们的sql语句逃逸出来从而执行，继续往下看，因为此时我们还不知道sql语句的结构

发现在80行我们的评论进入了filter_words函数

跟进一下发现只是对敏感词的一个过滤

继续往下看发现调用了single_insert来执行我们的语句

我们跟进去看一下sql语句的结构

发现我们传入的$fields会进行一个循环处理，然后对我们的数值进行一个' '的添加，key是不会添加'但是key我们并没有办法控制，我们只能控制value，在html实体转义之后我们输入的引号不会闭合之前的结构，所以我个人觉得这里是不存在SQL注入的，同样的ip也没做过滤但是我们仍然无法跳脱出引号。有可能我这个版本是漏洞修复后的吧。

未复现总结：

1. 参数实体化处理：$page['post'] 变量接收用户提交的评论数据后，系统会对传入的参数进行 HTML 实体化处理。该处理会将单引号、双引号等特殊字符转换为对应的 HTML 实体（如 ' 转换为 &#039;），使得攻击者无法通过闭合 SQL 语句中的引号来构造恶意的 SQL 命令。
2. 敏感词过滤而非 SQL 注入防护：在第 80 行，评论内容会进入 filter_words 函数，但该函数仅用于过滤敏感词，并未对 SQL 注入相关的特殊字符（如 union、and、or 等）进行有效拦截，不过结合前面的 HTML 实体化处理，已足以抵御 SQL 注入攻击。
3. SQL 语句构造安全：系统通过 single_insert 函数执行插入评论的 SQL 语句。在该函数中，$fields 数组会被循环处理，数值部分会被自动添加单引号包裹，而 key 部分由系统内部定义，用户无法控制。由于用户可控的 value 已被 HTML 实体化，无法突破单引号的限制，因此无法篡改 SQL 语句的结构，不存在 SQL 注入漏洞。

四、反射 XSS 漏洞审计

（一）漏洞原理与位置审计

反射型跨站脚本（XSS）漏洞存在于 callback.php 文件中，审计发现该文件在处理用户传入的参数时，未对参数中的 HTML 标签、JavaScript 代码等内容进行任何过滤与转义处理，直接将参数值输出到页面中，导致攻击者可构造包含恶意脚本的 URL，当用户点击该 URL 时，恶意脚本会在用户的浏览器中执行。

（二）漏洞验证与利用审计

攻击者可通过构造如下 URL 来验证并利用该漏洞：http://localhost/callback.php?param=<script>alert('XSS')</script>。当用户使用浏览器访问该 URL 时，页面会直接执行 <script> 标签中的代码，弹出包含 XSS 字样的弹窗，证明漏洞存在。

五、模板注入漏洞审计（后台 RCE）

（一）漏洞原理与位置审计

模板注入漏洞存在于后台管理页面的 admin/template.php 文件中，该文件用于编辑网站模板内容。在模板编辑功能中，$page['post']['content'] 变量直接接收用户输入的模板内容，且系统未对该变量中的代码进行安全校验与过滤，允许用户插入 PHP 代码片段。由于模板文件会被系统解析执行，攻击者可通过插入恶意 PHP 代码，实现后台远程命令执行（RCE）。

（二）漏洞利用步骤审计

1. 获取后台权限：攻击者需先通过猜测密码、暴力破解、利用其他前台漏洞获取管理员 Cookie 等方式，登录 Appcms 的后台管理系统。
2. 插入恶意代码：进入模板管理页面（对应 admin/template.php 文件），选择任意一个可编辑的模板文件，在模板内容中插入恶意 PHP 代码，例如 <?php system('whoami');?>。
3. 执行恶意代码：保存模板文件后，系统会自动解析并执行模板中的代码。攻击者可通过访问引用该模板的前台页面，触发恶意代码的执行，获取服务器的系统信息（如执行 whoami 命令获取当前用户身份），若权限足够，还可执行文件上传、服务器提权等进一步的攻击操作。

六、漏洞防御建议（基于审计结果）

针对上述审计发现的 Appcms 安全漏洞，为保障基于该系统搭建的网站安全，建议采取以下防御措施：

1.任意文件包含漏洞防御

对用户可控的路径参数（如 $tpl）进行严格过滤，采用白名单机制限制允许包含的文件路径与后缀，禁止使用 ../ 等目录遍历字符。

升级 PHP 版本至 5.3.4 及以上，修复低版本 PHP 中的路径截断漏洞。

加强文件上传功能的权限校验，仅允许已登录且拥有上传权限的用户发起上传请求，并对上传文件的类型、大小、内容进行严格检测，禁止上传包含恶意代码的文件。

2.SSRF 与文件读取漏洞防御

对 pic.php 文件中传入的 URL 参数进行严格校验，禁止访问内网地址（如 192.168.0.0/16、10.0.0.0/8 等私有网段），防止 SSRF 攻击对内网造成威胁。

限制可读取的文件类型与路径，通过白名单机制仅允许读取指定目录下的特定后缀文件，禁止读取配置文件、源码文件等敏感文件。

3.反射 XSS 漏洞防御

对 callback.php 文件中用户传入的所有参数进行 HTML 转义处理，将 <、>、script 等特殊标签与关键字转换为对应的 HTML 实体，确保用户输入的内容仅作为文本显示，不被浏览器解析为代码执行。

在网站的 HTTP 响应头中添加 Content-Security-Policy（CSP）头，限制页面中脚本的加载与执行来源，进一步降低 XSS 漏洞的利用风险。

4.模板注入漏洞防御

对后台模板编辑功能进行权限细化，仅授予核心管理员模板编辑权限，并开启操作日志记录，便于追溯模板修改操作。

在 admin/template.php 文件中，对用户输入的模板内容进行代码审计，禁止插入 <?php ?>、{php} 等可执行代码的标签，仅允许使用系统预设的模板标签与语法。