在一次授权靶场渗透测试中，我们对某 DEDECMS 靶场系统进行安全评估。
发现前台存在"申请友情链接"功能，提交后链接会进入后台管理员审核队列。
安全风险点：若攻击者提交的链接指向一个精心构造的 CSRF POC 页面，当管理员在已登录状态下点击该链接，可能触发后台敏感操作。
经验证，DEDECMS 后台的【核心】→【文件式管理器】功能允许创建 PHP 文件，且未校验请求来源（无 CSRF Token 或 SameSite Cookie 保护），存在 CSRF 漏洞。
【授权测试记录】
在 DEDECMS 前端底部发现"申请加入"（友情链接）功能入口。该功能将用户提交内容推送至后台审核队列。
测试确认：提交的链接会进入后端【模块 → 友情链接】的待审列表。
若该流程缺乏安全校验，可能被用于 CSRF 诱导链。
基于安全研究视角，我们思考：若攻击者提交一个指向 CSRF POC 页面的链接，当管理员在已登录状态下访问该链接，是否可能触发后台危险操作？
由于本次测试环境为本地搭建的授权靶场，我们已知后台管理地址。为验证上述假设，接下来进入后台，检查是否存在可被 CSRF 利用的危险功能点。
进入后台后，在【模块】→【友情链接】管理页面中，成功定位到此前从前台提交的测试链接。这验证了从前台提交内容可直达管理员操作界面的路径。
为进一步评估潜在风险，我们对后台功能进行授权范围内的安全排查 ，重点检查是否存在缺乏 CSRF 防护的危险操作接口（如文件管理、配置修改、用户操作等）。
经初步观察，若某功能允许执行高危操作（如创建脚本文件、修改系统配置）且未实施请求来源校验，则可能被结合 CSRF 利用，形成越权操作或远程代码执行风险。
在【核心】→【文件式管理器】功能中，我们注意到系统允许管理员在线创建任意类型的文件。进一步测试确认，该功能未限制文件扩展名，可创建 php文件 。
此类功能若缺乏访问控制与请求来源校验，将构成严重的安全风险。
为验证 CSRF 风险，我们在本地授权环境中进行如下操作：
- 在"新增文件"功能处捕获 HTTP 请求；
- 使用 某安全测试代理工具（如 Burp Suite）生成对应的 CSRF 验证载荷（PoC）；
- 将该 POC 页面部署于本地可控 Web 服务器（如
1．ｈｔｍｌ）； - 通过前台"申请友情链接"功能提交该 POC 链接；
当管理员在已登录状态下访问该链接 ，浏览器将自动向后台发起文件创建请求。若系统未实施 CSRF 防护，将非预期地生成指定脚本文件，从而暴露远程代码执行（RCE）风险。
（注：本实验仅用于安全研究，所有操作均在本地靶场完成，未对任何真实系统造成影响。）
需要说明的是：在真实渗透测试场景中，测试人员通常无法直接访问目标后端。
因此，正确做法是：
- 根据目标系统识别出的 DEDECMS 版本，在本地搭建相同环境进行漏洞复现；
- 基于复现结果，构造针对性的 CSRF POC；
- 再通过前端交互点（如友情链接、用户反馈等）诱导管理员触发该 POC。
这一过程完整模拟了外部攻击者可能利用的攻击链，有助于企业全面评估风险并部署有效防护。
接下来，我们捕获文件创建请求，并使用安全研究中常用的代理工具（如 Bp）捕获并分析请求，辅助验证 CSRF 风险，用于后续风险验证。
注意这里的路径是/upload，一般要返回上一层，才能来到该网站服务器根目录下。
开启抓包，构造一个用于验证 CSRF 风险的测试请求页面：
然后在自己的phpstudy服务器根目录下创建一个1.html，粘贴进刚才复制的POC：
测试还原环境完毕，再把这个test01.php给删除了
该文件可通过本地测试地址访问（示例：
http://192[.]168[.]88[.]1/s382/1．ｈｔｍｌ）
把上面那个URL放进前端链接，并提交：
后台显示出来了，点击进去，看看效果：
安全机制说明（拓展知识） ：
在实际攻防中，CSRF 攻击的成功与否高度依赖目标系统的防护措施：
- 若系统对风险操作引入了动态 Anti-CSRF Token（如每次请求生成唯一 token），由于攻击者无法通过 JavaScript 读取跨域响应（受同源策略限制），无法读取到动态token，将无法构造有效请求；
- 若 Cookie 设置了
SameSite=Strict或SameSite=Lax属性，浏览器在跨站请求时将不携带身份凭证Cookie，从而阻断 CSRF 利用链。
因此，完善的 CSRF 防护应结合 Token 校验与 SameSite Cookie 策略，这是现代 Web 应用的安全基线。
在本次授权测试中，我们观察到：仅当管理员处于已登录后端的状态下 ，访问 POC 页面（1.html）才会触发文件创建请求。
为确保复现稳定性，建议在测试过程中保留中间文件（如 test01.php），若首次未成功，可重新提交 POC 并验证是否生成目标文件。
实验结果表明：若防护缺失，系统将自动创建一个服务端恶意载荷文件（示例）。该文件若包含可执行逻辑，则可能形成"远程命令执行"类风险。
此类文件一旦被 Web 服务器解析，若包含动态逻辑 ，则可能带来不可控的安全后果。
这也是为何生产环境中应严格禁止后台创建可执行脚本。
修复建议：
- 对所有可能存在风险的操作（如文件创建、用户管理）增加 Anti-CSRF Token，并校验其有效性；
- 为身份认证 Cookie 设置
SameSite=Strict属性； - 限制文件管理器对服务端脚本类型（如 PHP、JSP 等）的创建权限；
- 关闭非必要后台功能模块，遵循最小权限原则；
- 升级至官方最新版 DEDECMS，或迁移到更安全的现代 CMS 系统。
#渗透测试 #DEDECMS #CSRF #授权测试 #学习笔记