首页/资讯中心/详情

OA与CMS系统漏洞挖掘：从权限边界突破到实战提权

OA与CMS系统漏洞挖掘：从权限边界突破到实战提权
📅 发布时间：2026/6/19 5:03:02

1. 项目概述：从“打点”到“权限”的经典路径

做SRC（安全应急响应中心）漏洞挖掘的朋友，对“打点”这个词一定不陌生。它听起来有点黑话的味道，但核心意思很直白：就是找到一个可以进入目标系统的初始入口点。你可以把它想象成一场渗透测试的“敲门砖”，或者一次战役的“登陆滩头”。而“OA系统”与“通用CMS”，恰恰是互联网上最密集、也最经典的“滩头阵地”。这个标题《OA系统与通用CMS —— 打点拿权限的“传统艺能”》精准地概括了无数白帽子、安全研究员日常工作中最频繁上演的戏码。所谓“传统艺能”，意味着这套方法历经时间考验，虽然防御手段在升级，但攻击面依然存在，甚至因为其“传统”而容易被忽视，从而成为我们挖掘漏洞的富矿。

为什么是OA和CMS？原因在于它们的普遍性和功能性。OA（办公自动化）系统承载着一个组织的核心业务流程，从考勤、审批到公文流转，里面全是敏感数据。而CMS（内容管理系统）则是网站建设的基石，从政府门户、企业官网到个人博客，背后可能都是同一套CMS程序。这两类系统为了满足灵活的业务需求，往往功能复杂、交互点多，并且大量采用开源或商业框架进行二次开发。这就带来了一个根本矛盾：功能的复杂性与安全开发的成熟度之间的落差。开发团队可能更关注业务逻辑的实现，而将安全视为“配置项”或“后期加固”，这就为漏洞留下了空间。

“打点拿权限”这个短语，则清晰地勾勒出了一条攻击链。它不是一个孤立的漏洞点，而是一个有步骤的过程：“打点”是发现入口（比如一个未授权的API接口、一个暴露的管理后台登录页）；“拿权限”则是通过这个入口，利用漏洞（比如SQL注入、逻辑缺陷、文件上传）逐步提升自己的权限，从普通用户到管理员，甚至到服务器系统权限。这个过程考验的不仅是漏洞利用技巧，更是对目标系统架构、业务逻辑的理解能力。接下来，我们就深入这套“传统艺能”的内核，看看如何系统性地进行挖掘。

2. 核心思路：权限边界的模糊地带是主战场

在SRC漏洞挖掘中，尤其是针对OA和CMS这类应用，我的核心思路始终围绕一个中心：权限边界。任何安全漏洞，本质上都是对预期权限边界的一次突破。因此，挖掘工作不是漫无目的地扫描，而是有策略地寻找边界上最薄弱的环节。

2.1 理解“权限模型”是第一步

在动手之前，你必须先理解目标系统大概的权限模型。对于OA和CMS，常见的模型包括：

  1. 基于角色的访问控制（RBAC）：这是最普遍的。用户被赋予角色（如“员工”、“部门经理”、“系统管理员”），角色拥有权限集合。漏洞常出现在角色权限分配错误、权限校验缺失或绕过上。
  2. 基于访问控制列表（ACL）：直接为用户或用户组对某个资源（如文件、功能模块）设置具体的操作权限（读、写、执行）。漏洞可能出现在ACL列表遍历、越权访问上。
  3. 混合模型：上述两者的结合，更为复杂，也更容易出现逻辑不一致。

你需要通过信息收集，尝试判断目标所用的模型。查看登录后的菜单、功能点，尝试注册不同账号（如果有开放注册），观察权限差异。很多CMS的默认后台路径是/admin、/wp-admin（WordPress）、/admin.php，OA系统则可能是/oa、/login、/portal等。这些地方是权限模型的“指挥部”，也是我们重点观察的对象。

2.2 攻击面枚举：从外到内，从广到深

确定了目标，接下来就是系统地枚举攻击面。我习惯将其分为四个层次：

  1. 未授权访问/弱权限点：这是最理想的“打点”目标。包括：

    • 暴露的管理后台：搜索引擎语法（如site:target.com inurl:admin）、目录扫描工具（如 dirsearch, gobuster）可以帮助发现。
    • 默认口令与弱口令：针对admin、test等默认用户，或使用常见弱口令字典进行爆破。许多OA和CMS在初始安装后并未强制修改默认密码。
    • 无需认证的API接口：通过抓包分析（Burp Suite, Fiddler），寻找那些本应校验身份却直接返回数据的接口。例如，某些CMS的新闻列表API、图片上传接口可能缺乏鉴权。
    • 信息泄露：.git源码泄露、DS_Store文件、配置文件（如config.php.bak）、错误信息回显等，可能直接泄露数据库密码、加密密钥等关键信息。

  2. 已授权用户的越权漏洞：这是“拿权限”的核心。分为两类：

    • 水平越权：能访问/操作同级别其他用户的资源。例如，通过修改URL中的用户ID参数（如/api/user/profile?id=123），可以查看到用户456的资料。
    • 垂直越权：低权限用户能执行高权限用户的操作。例如，一个普通员工通过构造请求，可以访问到本应只有管理员才能看到的后台管理页面或执行管理操作。

  3. 代码执行与文件操作：这是权限提升的“王牌”。常见入口有：

    • 文件上传漏洞：上传功能未对文件类型、内容进行严格校验，导致可上传Webshell（如.jsp、.php、.asp木马文件）。
    • 模板注入/代码注入：某些CMS的模板编辑功能或内容渲染引擎存在缺陷，允许注入可执行的代码。
    • 反序列化漏洞：在Java、PHP等语言的OA系统中较为常见，通过构造恶意的序列化数据，触发远程代码执行。

  4. 供应链与第三方组件漏洞：OA和CMS大量使用开源框架（如Spring Boot, ThinkPHP）、中间件（如Redis, Fastjson）、编辑器（如UEditor, KindEditor）和插件。这些组件的已知漏洞（NVD, CNVD有记录）往往是通杀漏洞。你需要识别目标使用的组件及其版本。

注意：在SRC挖掘中，未经授权的测试是绝对禁止的。所有测试必须在获得目标所有者明确授权（通常通过SRC平台提交测试申请）后进行。对于未公开的、或你怀疑存在但未公开的漏洞，应遵循负责任的披露流程。

3. 实战演练：针对两类系统的专项挖掘策略

有了核心思路，我们进入实战环节。我会分别针对OA系统和通用CMS，分享一些具体的挖掘路径和案例。

3.1 OA系统漏洞挖掘实战要点

OA系统业务逻辑复杂，用户角色多，是逻辑漏洞的沃土。

3.1.1 入口发现与信息收集

  • 子域名与端口：使用工具（如OneForAll, subfinder）收集目标关联的所有子域名和开放端口。OA测试环境、移动端接口、旧版本系统可能就在某个不起眼的子域上。
  • 目录与文件扫描：除了通用字典，要加入OA相关字典，如/seeyon/（致远OA）、/weaver/（泛微OA）、/ispirit/（泛微）、/yyoa/（用友）等路径。
  • 指纹识别：使用工具（如Wappalyzer, EHole）识别OA品牌和版本。知道是致远、泛微还是蓝凌，就能快速关联其历史漏洞和默认配置。
  • JS文件分析：现代OA前端大量使用JavaScript，其中可能硬编码了API路径、接口参数甚至测试账号信息。用浏览器开发者工具仔细查看。

3.1.2 核心功能模块测试

  1. 登录与认证模块：
    • 密码爆破与锁定机制绕过：测试登录失败次数限制是否可被绕过（如修改Cookie或IP）。
    • 验证码漏洞：验证码是否可重复使用、逻辑绕过、或识别（OCR）。
    • 密码找回逻辑缺陷：这是重灾区。测试是否可通过修改响应包、跳过验证步骤、短信轰炸导致验证码泄露、或利用邮箱/手机号篡改来实现任意用户密码重置。
  2. 流程审批模块：
    • 越权审批/查看：尝试作为普通用户，能否通过接口调用或修改参数，审批或查看其他部门、更高级别的流程。
    • 流程绕过：能否通过前端修改、重放请求等方式，跳过某个审批节点直接进入下一环节或结束流程。
  3. 文件管理与邮件模块：
    • 任意文件上传：重点关注附件上传、个人头像上传、文档导入等功能。测试绕过前端校验（抓包改Content-Type、文件名）、黑名单绕过（.php5,.phtml, 大小写）、解析漏洞（IIS6.0, Nginx解析漏洞）。
    • 任意文件下载/读取：通过目录遍历漏洞（如参数中包含../../etc/passwd），读取服务器上的敏感文件，如配置文件、源码、日志。
  4. 个人信息与通讯录模块：
    • 水平越权：修改userId、employeeId等参数，查看、修改他人个人信息、工资条、考核结果。
    • 敏感信息泄露：通讯录查询接口是否未做权限控制，导致可导出全公司人员信息。

3.1.3 一个典型案例：密码找回的逻辑黑洞

我曾在一个企业自研的OA系统中发现过一个经典的逻辑漏洞。其密码找回流程如下：

  1. 输入用户名 -> 系统向绑定手机发送短信验证码。
  2. 输入短信验证码 -> 跳转到设置新密码页面。

问题出在第二步的验证上。我通过Burp Suite拦截了“提交验证码”的请求，发现响应包中直接包含了一个success: true的字段和一个resetToken。我尝试将验证码改为一个错误的值，但服务器依然返回了success: true和同样的resetToken！这意味着，服务器端根本没有校验我输入的验证码是否正确，只要这个请求接口被调用，它就认为验证通过，并下发重置令牌。我随后直接用这个resetToken访问设置新密码的页面，成功重置了任意用户的密码。这个漏洞的根源在于开发人员将“流程步骤”等同于“安全校验”，认为用户到达第二步页面就一定是通过了第一步的验证，这是一种危险的前后端状态依赖。

3.2 通用CMS漏洞挖掘实战要点

CMS的目标是快速建站，因此默认安装、通用插件、主题模板是主要风险点。

3.2.1 快速定位与版本识别

  • Robots.txt 与 Sitemap.xml：这些文件通常会暴露后台路径、插件目录。
  • 特定文件指纹：访问/wp-includes/version.php（WordPress）、/dede/（织梦）、/e/install/index.php（帝国CMS）等，查看版本信息。
  • 错误信息：故意触发一个404或错误，看是否返回具体的CMS名称和版本。

3.2.2 核心漏洞类型挖掘

  1. 后台入口与弱口令：这是最直接的“打点”。尝试默认后台路径和默认账号密码（admin/admin）。很多站长安全意识薄弱，安装后从不修改。
  2. SQL注入漏洞：
    • 搜索型注入：CMS的搜索功能是SQL注入高发区。测试搜索框、标签筛选、文章分类筛选等参数。
    • 后台注入：后台管理功能，如内容编辑、用户管理，参数过滤可能不如前台严格。
    • 盲注与时间盲注：由于错误信息可能被屏蔽，需要熟练使用布尔盲注或时间盲注技术进行判断。
  3. 文件上传与包含漏洞：
    • 编辑器上传：FCKeditor、UEditor、KindEditor等网页编辑器历史上漏洞百出。测试图片上传点，尝试上传含有一句话木马的图片马（利用文件头欺骗），并结合文件包含漏洞执行。
    • 模板文件上传：某些CMS允许管理员上传自定义模板文件（.php, .tpl），如果过滤不严，可直接上传Webshell。
    • 本地文件包含（LFI）/远程文件包含（RFI）：通过参数包含服务器本地文件（如?file=../../config.php）或远程恶意脚本。
  4. 插件与主题漏洞：
    • 这是CMS漏洞的“重灾区”。一个流行的CMS本身可能比较安全，但其海量的第三方插件和主题质量参差不齐。需要关注插件/主题的更新日志、安全公告，并对其独立代码进行审计。
  5. 权限绕过与未授权访问：
    • 某些CMS的前台用户功能（如投稿、评论）与后台管理功能共享了部分API，可能通过构造特定的请求，在前台触发后台管理操作。
    • 直接访问需要登录的页面，观察是跳转到登录页，还是仅仅隐藏了功能按钮但接口仍可调用。

3.2.3 一个典型案例：从SQL注入到Getshell

在一次对某知名开源CMS的审计中，我发现其文章评论功能存在SQL注入。注入点位于评论者邮箱的参数过滤不严。利用这个注入点，我首先通过union select读取了数据库中的管理员用户名和密码哈希值。但密码是加盐哈希，破解需要时间。

于是，我转向利用该CMS的一个特性：它允许管理员在后台通过“数据库管理”功能执行SQL语句。虽然我还没有后台权限，但我发现这个执行SQL的功能对应的PHP文件是/admin/db_execute.php。我直接访问这个文件，它果然提示“未登录”。但是，我通过之前SQL注入获得的信息，知道了该CMS的Session是如何生成的（基于用户ID和固定盐值）。我通过注入点，向数据库插入了一条我自定义的管理员用户记录（需要绕过一些约束），并计算出了这个新用户的Session ID。

随后，我使用这个伪造的Session ID修改浏览器Cookie，再次访问/admin/db_execute.php，成功进入后台。在数据库执行功能里，我直接执行SQL语句，将一句话木马写入了一个可访问的PHP文件中（例如SELECT '<?php @eval($_POST[cmd]);?>' INTO OUTFILE '/var/www/html/shell.php'），最终成功获取了Webshell。这个案例串联了SQL注入、逻辑缺陷（Session生成机制可预测）、后台功能滥用多个漏洞，完成了从“打点”到“拿权限”的完整链条。

4. 工具链与自动化辅助

手工挖掘是基础，但合理的工具能极大提升效率。我的工作流通常如下：

  1. 信息收集阶段：

    • 子域名：OneForAll, Subfinder, Amass
    • 端口扫描：Nmap, Masscan
    • 目录/文件扫描：Dirsearch, Gobuster, ffuf
    • 指纹识别：Wappalyzer (浏览器插件), EHole, WhatWeb
    • 历史记录：Wayback Machine, SecurityTrails

  2. 漏洞探测阶段：

    • 代理与抓包：Burp Suite Professional (核心)， Fiddler
    • 主动扫描器：Burp Scanner, AWVS, Xray （谨慎使用，避免对目标造成压力）
    • 专项漏洞检测：
      • SQL注入：sqlmap
      • XSS：XSStrike, dalfox
      • 命令/代码注入：Commix
    • 框架/组件漏洞利用：根据识别出的指纹，搜索对应的公开Exp或编写POC。

  3. 权限提升与后渗透（在授权范围内）：

    • Webshell管理：AntSword (蚁剑), Godzilla (哥斯拉)
    • 内网探测：frp, ngrok (用于隧道穿透)， Nmap (内网扫描)
    • 信息收集：LinPEAS (Linux), WinPEAS (Windows) 用于本地提权信息枚举。

实操心得：工具不是万能的，但不会用工具是万万不能的。我的原则是：让工具做重复和模式化的工作，用人脑做分析和判断。例如，用扫描器发现疑似注入点，但一定要手工验证其真实性、判断注入类型、思考如何绕过WAF。Burp Suite的Intruder和Repeater模块是手工测试的“左右手”，必须非常熟练。

5. 漏洞挖掘中的高阶思维与技巧

掌握了基本方法和工具后，要想挖到高质量的漏洞，还需要一些高阶思维。

5.1 “黑盒”与“白盒”的结合

SRC挖掘大多是黑盒测试，但我们可以无限逼近“灰盒”。

  • 寻找源码：通过.git泄露、备份文件、安装包下载等方式，尝试获取目标系统的部分或全部源码。
  • 关注开源项目：如果目标使用的是知名开源OA或CMS（如Ruoyi， Jeecg-Boot， WordPress），直接去下载一份相同版本的源码进行本地审计。你在源码中发现的漏洞，很可能在目标系统上也存在。
  • 反编译与调试：对于Java的.jar包或.NET的dll，可以使用反编译工具（如JD-GUI, dnSpy）进行分析。

5.2 业务逻辑深度理解

漏洞往往藏在业务的“角落”里。你需要真正理解这个功能是做什么的。

  • 换位思考：如果你是开发者，为了实现这个功能，你会怎么写代码？哪里最容易出错？（比如，忘记做权限校验、认为某些参数不可被用户控制）。
  • 多角色测试：如果可能，注册或获取不同权限的账号（用户、编辑、管理员），观察同一功能在不同角色下的请求差异。
  • 流程穿越：不按正常步骤操作。例如，在支付流程中，直接尝试访问“支付成功”后的页面；在审批流程中，尝试撤回已提交的申请并重新提交到其他节点。

5.3 绕过技巧的积累

现代应用都有一定的防护（WAF、输入过滤）。

  • SQL注入绕过：学习大小写、双写、编码、注释符、等价函数替换等技巧。
  • 文件上传绕过：Content-Type、文件名、文件头、.htaccess、配合解析漏洞。
  • XSS绕过：HTML事件、JavaScript伪协议、编码、利用SVG等标签。
  • 规律总结：把每次遇到的防护和绕过方法记录下来，形成自己的知识库。

6. 常见问题排查与修复建议实录

在挖掘和后续的漏洞修复沟通中，会遇到一些典型问题。

6.1 漏洞复现与证明

这是提交漏洞报告时最关键的一步。报告必须清晰、可复现。

  • 步骤明确：像写教程一样，1，2，3... 写清楚每一步操作、输入的参数、看到的页面。
  • 证据确凿：使用Burp Suite截取完整的HTTP请求和响应包，以文本形式粘贴在报告中。关键部分（如恶意参数、成功回显）用高亮标出。
  • 影响说明：客观描述漏洞可能造成的影响（如信息泄露、权限提升、数据篡改），避免夸大。
  • 修复建议：提供具体的修复方案。例如，对于SQL注入，建议使用参数化查询（Prepared Statement）；对于越权，建议在服务端对每次请求都进行会话和权限校验。

6.2 开发人员的常见误解

与开发人员沟通时，他们可能会有一些误解，需要你耐心解释：

  • “前端做了校验就行了”：必须强调所有安全校验必须在服务端进行，前端校验仅用于提升用户体验，可被轻松绕过。
  • “这个功能只有管理员能用，所以没问题”：需要解释垂直越权的概念，即如何从普通用户权限“爬升”到管理员权限，或者管理员Cookie被盗取的情况。
  • “我们用了框架，很安全”：框架提供了安全基础，但不正确使用框架（如错误配置、使用不安全的方法）同样会导致漏洞。例如，Spring Security配置不当会导致权限绕过。

6.3 自己挖洞时的“坑”

  • “扫不出来，就是没漏洞”：扫描器不是神器。很多逻辑漏洞、新型的绕过手法，扫描器根本无法发现。深度依赖手工测试和逻辑分析。
  • “这个点别人肯定测过了”：不要有这种心理。每个人的思路和测试深度不同。一些看似普通的点，深入下去可能有新发现。特别是业务逻辑，千变万化。
  • “急于求成，浅尝辄止”：看到一个登录框就只测爆破和验证码，看到一个上传点就只测常见后缀。应该系统地、多角度地测试每一个输入点和功能流。

6.4 漏洞修复后的验证

提交漏洞后，要跟踪修复情况。在厂商修复后，需要进行验证测试，但要注意：

  • 获得再次测试的授权。
  • 不要使用原来的PoC：厂商可能只针对你的PoC做了修补。尝试用变形的Payload、不同的攻击路径去验证漏洞是否被根本性修复。
  • 关注“修复”引入的新问题：有时修复一个漏洞（如增加过滤）可能会破坏正常功能或引入新的安全风险。

7. 从实战到沉淀：构建个人漏洞挖掘体系

最后，我想分享的是，漏洞挖掘不应该是一次性的“碰运气”，而应该成为一个可持续、可复现的体系化过程。

7.1 信息管理与知识库

我使用Notion或Obsidian来搭建个人知识库。里面会分门别类地记录：

  • 目标资产清单：我关注的公司、其子域名、主要系统、使用的技术栈。
  • 漏洞模式库：将遇到过的漏洞按类型（SQLi， XSS， 越权， 文件上传， 逻辑漏洞）、按技术（Java反序列化， Fastjson， Shiro）、按厂商（泛微OA某版本漏洞， WordPress某插件漏洞）进行分类记录，包括漏洞原理、利用条件、Payload、修复方案。
  • 工具使用笔记：每个工具的常用命令、参数、使用技巧和踩坑记录。
  • 阅读与学习笔记：从安全博客、论文、CTF Writeup中学到的新思路、新技巧。

7.2 工作流固化

将成功的挖掘过程固化成 checklist 或脚本。

  • 信息收集Checklist：每次面对新目标，都按照固定的清单进行信息收集，确保没有遗漏。
  • 通用测试点Checklist：针对登录、注册、密码找回、上传、查询等通用功能，列出必须测试的项目（如：登录的爆破、锁机绕过、验证码；上传的文件类型、内容、路径）。
  • 自动化脚本：对于重复性高的工作，比如用特定Payload批量测试一批URL中的参数，可以编写简单的Python脚本配合Burp的API或直接使用Requests库来完成。

7.3 心态与法律边界

  • 保持好奇心与耐心：漏洞挖掘是技术和耐心的结合。一个看似正常的页面，背后可能有十几种攻击向量。
  • 严守法律与道德底线：只在获得授权的范围内进行测试。不触碰、不泄露任何未授权的数据。通过合法渠道（SRC平台）提交漏洞。
  • 拥抱分享与交流：在遵守规则的前提下，多和社区交流。看别人的漏洞报告，学习他们的思路和方法。分享自己的经验，也能获得反馈和进步。

这套针对OA系统和通用CMS的“传统艺能”，之所以经久不衰，正是因为这些系统在追求功能、效率和易用性的同时，安全往往被置于次要位置，或者因为复杂的业务逻辑而难以面面俱到。作为挖掘者，我们的价值就在于用攻击者的思维，帮助开发者发现这些盲点。这个过程就像一场永不停歇的攻防博弈，而深入理解权限边界、业务逻辑和人性弱点，永远是其中最核心的武器。每一次成功的“打点”和“拿权限”，背后都是对系统的一次深刻理解，而不仅仅是工具和Payload的简单堆砌。