EDUSRC、CNVD挖洞技巧分享|如何快速获取证书

前言声明：

文章所涉及漏洞案例均在多月前已提交至相关平台进行修复，且所涉及的敏感信息均已做打码处理

本文章仅用于网络安全技术研究与合法授权环境下的学习交流，旨在增强信息安全意识、提升防御能力，不构成对任何攻击行为的鼓励或支持。本文不支持、不宣传、不引导任何形式的网络攻击行为，亦不为非法用途提供技术帮助。文章所探讨的技术具有中立性，其正当用途在于帮助相关单位及安全从业者识别系统风险、提升防御能力，从而更好地保障广大用户的信息安全与数字权益。最后倡导以攻促防、依法研究、技术向善。

一：框架之指纹识别刷洞，以及供应链挖掘技巧。

如下：

CNVD EDUSRC 挖洞技巧三部曲分析（一）| 赏金猎人

在搜索引擎上根本就没有这个系统的web.icon图标，这里就是说到如何提取前端源码指纹去搜索了

这里右键点开查看源码，然后指纹识别一下，大概有以下几步：

1.静态资源路径和文件名（JS、CSS、图标），特定框架或厂商常用文件夹名：如 /assets/、/Public/lib/、/vendor/laravel-admin/。

2.引入的 JS 库和组件库，明确显示了使用 Vue、React、Arco Design、Element UI、layui、AdminLTE、jQuery 等，这些库本身就有指纹特征。
3.DOM 样式结构和 class 名，例如 layui-container、login-logo、login-form 等命名具有特定风格。
4.网络请求或隐藏字段，表单提交路径（如 /Admin/dologin、/dt.php/ajax/upload）可能暴露后端框架或接口命名规范。隐藏 token 字段（如 __token__）可判断是否使用 ThinkPHP、Laravel 等框架。

/Public/lib/layui-v2.6.3/layui.js

layui-input / layui-icon layui-icon-username

到这里可以直接用body="/Public/lib/layui-v2.6.3"&&body="layui-input"  精准搜索

得出来的title标题boby都不一样，但是几个系统其实框架都是一样的，但是可见这些指纹特征

还有就是面对魔改的系统，很多开发运维他会直接把原来框架的图标换成单位公司的图标，这时候在搜索引擎上的web.icon的哈希值肯定是会变动，但是通过前端源码提取相关指纹也是可以做到确定框架系统的。这里就说到，扩展版了

body="layui-icon layui-icon-username" && body="admin-login-background"

大型资产测绘，能识别到基于 Layui UI 前端框架 且有一定相似结构的后台登录系统，不局限于 LayuiMini。哪怕系统 UI 改了资源路径、换了 Layui 版本，但页面结构与类名没动，也能匹配，适合大范围指纹识别。因为用的是页面 HTML 结构和类名，不依赖具体 JS/CSS 文件路径。这里你可以看到直接就变成1.4W条信息了。

但是这里又重新出现一个问题。

这个很明显是一个ThinkPHP框架的Favicon

那到底是ThinkPHP框架还是Layui  框架？

此外这里要强调也有一种特别的情况：老练又“阴间”的开发行为套路了。

“外壳伪装术”：伪造指纹、误导识别、反打诱饵

一些开发人员，尤其是维护比较敏感系统，会做下面这些事，就是为了干扰红队/渗透测试人员的判断：渗透者看到 favicon=ThinkPHP，就会误以为后端是 TP 框架，然后你用  ThinkPHP扫，全打不中。一些“钓鱼式诱导防御”系统特意伪装出 TP、JEECG、SpringBoot、OA系统等特征，吸引扫描器去打无效 payload，诱发告警。

但是具体情况还得具体分析，也有很多是基于 ThinkPHP 后端 + Layui 前端 UI 框架构建的典型后台管理系统。这个看前端页面是这样的，后续抓个包看一下请求和响应就知道了。

那么结果就很明显了，是基于 ThinkPHP 后端 + Layui 前端 UI 框架构建的典型后台管理系统。

可能这里又有一些同学想说：哪来这么复杂！我直接用一些指纹识别工具一跑不就出来了嘛。我这里以指纹识别的工具为例，结果也确实可以跑得出来。

但是再遇到其他魔改版本试试，接着来看：访问确实是正常，但是却识别不出来了.

我们接着来举例魔改版本分析：

看样子也还是Layui 前端，从Wappalyzer根本没看到任何PHP痕迹，前端完全没有 .php 请求
没有看到 /index.php、index.php?s=/admin/login 这类 URL
没有 ThinkPHP 特有的 __URL__, __ROOT__, U() 等标志
没有 .php 后缀的验证码或控制器地址，再看JS这里：

在实际过程中，Cookie命名也往往是最直接的后端框架指纹识别之一。到这里基本有85%-90%的几率指纹识别判定为Java JFinal 框架，可能又有同学问了，这怎么才85%-90%几率，那剩下15%是什么情况？难道没有100%指纹识别的办法嘛？

这个问题，特别是面对一些定制的开发系统，我认为根本没有100%判定的的指纹识别方法。

但是我们可以通过多方面情况和条件来综合判断指纹。
继续看如下案例：正常登录抓取返回包分析，或者构造一些传参为空，看响应触发业务校验逻辑，构造服务端抛异常，构造非法参数或非法路径，引发服务端逻辑异常等等

正常登录抓取返回包如下：

综上所述这大概率有99%就是 Java JFinal 框架。如果你用PHP的漏洞打，那根本就没用。

所以不要觉得：用了 Layui，就是用了某种后端语言（比如 PHP、ThinkPHP）

这里再挑选个一个例子：同样的工具识别不出来框架,看起来Layui的前端

URL 路径为 /system/login/loginPhone，这是典型的 Spring Boot Controller 路由命名风格。参数为 x-www-form-urlencoded，后端响应为结构化 JSON，
Spring Boot 默认采用@RestController结合@PostMapping接收表单参数，到这一步大概已经有80%多的几率确定是Spring Boot框架了，具体还差点意思......

其实最直观简单的就是：让页面报错就可以看出来了，那么如何报错呢？
我请求个/system/login/loginPhone  还有其他路径都发现被开发自定义的错误页面（要不然就是直接返回主登录口页面），之所以这样就是为了把原本可能暴露框架细节的错误信息屏蔽了。
最后试了一下/error   还是给我显示了  Spring Boot 默认错误页 —— Whitelabel Error Page！

接下来这里我要讲的就是如何选择优化，提取指纹信息了

这里再以若依某版本系统举例子，蓝若依框架如下：

web.icon=="e49fd30ea870c7a820464ca56a113e6e"

这是一种根据web.icon  提取蓝色小草若依版本的，但是有些开发会直接把这套源码拿来魔改，最基本的魔改就是直接web.icon 换成自己公司/单位的logo商标或者校徽。如果logo换了，那么这条语法就搜不出相对应的资产出来了，这里继续就说到指纹识别提取了。

经典若依样式资源路径，那么拼接语法就是

body="/ruoyi/css/ry-ui.css" && body="/ruoyi/login.js"

验证码接口特征

body="/captcha/captchaImage?type=math" && body="validateCode"

好了，我们来尝试一下，通过指纹提取，搜索，你会发现资产出来了，同样的框架，但是不同样的web.icon图标，这说明，有些就算魔改了，也能通过一些指定特征来识别出来。

那除了以上那些条件指纹识别，还有吗？ 那肯定也有啊。

JS资源路径匹配 + 标识变量，这里其实前端 JS 中定义 captchaType = "math" 也是若依默认行为。

body="/ruoyi/js/ry-ui.js" && body="var captchaType = \"math\""

有些它甚至把图标隐藏了，也可以识别出来

但是总得来说，还有其他结合识别语法，我这里先结合上面三条语法来确定哪条是最优的。

body="/ruoyi/css/ry-ui.css" && body="/ruoyi/login.js"      A组合指纹识别
body="/captcha/captchaImage?type=math" && body="validateCode"    B组合指纹识别
body="/ruoyi/js/ry-ui.js" && body="var captchaType = \"math\""   C组合指纹识别

这里我个人觉得从抗魔改层面出发稳定性最强的是B组合

1. 字段识别 validateCode 是登录表单中验证码输入框的字段名，这属于 表单逻辑命名，即使 UI 魔改、打包压缩，该字段名极少会变，否则整个验证码验证流程就失效。字段名不像路径或文件名那样容易替换。

2. 接口行为识别
/captcha/captchaImage?type=math 是若依默认的验证码获取接口（返回数学验证码图片），
这个结构在：
框架内部逻辑中，Spring Boot 控制器路由中，登录逻辑依赖中，都是深度绑定的。
所以很多魔改版依然使用这个路径，因为如果改了它，整个验证码模块都要重新设计。

3. 几乎与 UI 无关，前端怎么改都不中断识别
不依赖 login.js、ry-ui.css、title、logo 等容易被魔改的内容
不依赖变量名、组件名等易压缩项
只看接口路径 + 表单字段名，是最低级但最精准的指纹切入点。

唯一缺点：
在极少数完全禁用验证码的版本中（如关闭验证码），这条失效；但实际场景里，若依默认开验证码，99.9%开发我想应该都不会动这个功能。

当然最直观的你完全可以直接依赖搜索引擎的app 或者app.name语法这些，也可以直接搜出来一些魔改的框架，但是对比数量，上面的指纹识别语法都是3万多条起步，通过这个语法却只有1万9千条，是不是有点弱了。。。。刷洞上分就是拼的谁弹药库（漏洞库的子弹）多，谁信息收集的资产全面，你要拿到比别人更多范围，更广的资产，所以通过审计前端代码，寻找提取指纹这个你是必须要学会的。如果遇到一些自主开发的陌生框架，刚好你又测到漏洞点，那直接就是通杀了，就是这个意思。

使用者资产归属，这里我分类为：

从ICP备案中，显示并不为该大学的，但是里面确确实实有该大学的数据，怎么解释？

这里我分析有两种情况：

第一、数据由学校采集，但系统归企业运维；监管归教育局，最后资产挂企业名下，这是现在比较常见的。

第二种情况就是，漏洞归属单位应为网站实际使用者，而非软件或动态域名服务提供商。网站的实际使用者应该就是XX大学，而非XX公司。当然，XX网络服务提供商就是该大学的供应链。

明显常见的一般在登录口，版权处标有：

技术支持：XX公司

运维：XX公司

有问题请联系：XX公司

版权所有：XX公司 （但是进去后又发现，有某学校，学院，教育局，大学等教职工或者学生的数据）这些情况都属于第一种

那么，既然这家公司为这所大学提供网络服务，是不是也为其他学校提供呢，我的经验来看：几率挺大的

这里我就介绍到另外一条搜索语法了

icp.name="XX公司"  （列出该公司的在互联网上备案的ICP网络资产）在实际工作任务中

同样的，在做企业项目，甲方任务等，如果只给单位名称怎么做信息收集？  运用这条语法就可以了。

拿到ICP备案一搜，对应的IP就出来了，拿IP，然后扫端口，扫C段，接着再举一反三系列

继续拿开放的资产、系统等等，做指纹识别，再打点之类的......  这不就来活了嘛

好了，继续看案例哈，某天试了一个系统直接就来弱口令了。但是从域名ICP备案中只是公司而已，并不是该学校的域名备案，从数据上看有学生，教职工，家长数据还有饭卡等充值权限。确定得出来是某中学的供应链无疑了。从搜索引擎中看到还是个有图标搜索的，那么这里就直接捕捉web.icon图标，根据哈希去再搜索资产，果然不出我所料，还是存在多个学校资产的，虽然ICP备案也不同，但是都不影响。

有几个系统直接都是弱口令，于是赶紧陆续写了几份报告提交，但是最后审核都重复了

（我想也是，用最淳朴的方式捡rank就是比谁手快）爽了，捡到你就爽了。

但有一系统并没有说是具体什么技工学校。最后我找了一份教职工员工名单去溯源证明资产。最后在姓名，职务，以及办公室单位都对上了。溯源成功！直接就一个高危到手（还有系列充值卡权限等等）

我承认你是捷足先登，但最后还是我略胜一筹。

另外就是归属存疑，但是：校长，你也不想贵校教职工和学生的数据一起在互联网上裸奔吧。

回归第一篇章主题，总结来说：尽管该系统ICP备案主体为某公司，但其服务内容显然为教育信息化系统，且所泄露的所有数据均为学校生成、归属教育系统管理的数据。。我始终认为，网络安全不仅关乎技术，更关乎公众利益与社会信任。因此，能够发现并通报这些问题后提交并协助向教育主管单位推动修复，以个人能力行动能切实保护到广大公民信息和在校师生及其家庭的信息安全。
正是当初我学习网络安全的初心与意义所在。

2025年上半年我空闲时挖过的公益漏洞，毫不夸张地说涉及的数据达几千万条，同时也维护了公民的信息安全，也成功防止了公民的信息泄露。

4月份提交过某公司92万，也是接近百万数据泄露漏洞。

至于为什么没有拿企业赏金漏洞案例说呢，企业赏金SRC我也挖过一些，但是我挖的大多都是中低危不够价值的漏洞，这里我就不好意思摆上来秀了（我是散修出身，自己也不是计算机、网安科班出身，中途也没有什么系统性学习，都是看一些杂七杂八的技术文章，缺失的课程，以及二手网安书等等最后结合实战各种类型网站系统总结出来的，渗透时长大概是两年半吧）

二：弱口令刺客，人社资产探探乐。

对于弱口令在SRC中，我从来都不爆破，因为爆破这东西，一些小站点搞不容易就直接崩了，除了有授权的渗透项目或者是 攻防项目我才会用爆破，理由很简单：1.现在的站点几乎都做各种验证码，点击或是滑动图标、动物、图案，还有次数限制锁IP、锁账号、锁次数等等，针对于这种想爆破还要弄代理池，逆向等，我觉得太麻烦，干脆一套撼山拳打完就走。

只要你信息收集能力强，加上我上面说的使用者资产归属篇章，纯手撸也可以出洞。不信看以下案例：全是今年的，EDUSRC还意外收获若干张211 985大学漏洞报送证书。（以下我挑了一些已经修复的案例放出来，具体敏感信息都打码了）

登录口一看就是若依框架对吧，里面关键是有数据的（数据 = 敏感信息泄露，这点收不收很重要）

案例：又是一个211 985大学的案例，当时该校刚上证书的时候，我就马上交了。

数量粗略估计存在数万名博士生，硕士生，导师等档案信息

其他高校单位案例：

11W+ 条教职工和学生数据

10万+教职工和学生数据

人社资产探探乐系列

正常的就：XX社保系统、社会保障档案管理等服务.

就业驿站、就业服务中心系统、讨薪平台 / 投诉举报系统、劳动仲裁等

学校类： 技工学校，技师学院，还有如“技工院校管理平台”、“职业技能等级认定平台

人才类：学籍学历与人才信息交叉的系统，人才引进，包括部分地区的人才公寓管理系统等

资产+打点思路直接授人以渔了，我当时心血来潮也刷了一波，确实也出了不少货。

案例四：漏洞挖到了，系统也进去了，数据也拿到了，但就是不知道是哪个学校的?

如果对溯源全面具体可以看一下这篇，这里我只是部分引用。

从学生管理模块，直接是17000+学生档案信息，直接看身份证号码处是脱敏处理的，但是点击详情

学籍信息处直接可以看到完整的身份证号码。这个信息就全面了。

但是问题来了，该系统并没有备注任何公司或者学校的名称，只有学生跟教职工的信息，这里如何确定属于哪个学校的资产呢？这里就接触到溯源了，我从学生请假模块这里，抽了一个同学的手机号码出来，直接贴在手机通讯录中，利用抖音导入通讯人功能成功找出了她的抖音，主要的是抖音如果不进行隐私设置，一般是可以看到IP地址的，还有发作品的时候都有选择是否贴上地址，然后通过她的定位和作品都为XXX学院，流程如下：

既然确定了学院，后续就是找了一份奖学金名单，抽了几个同学，在该系统中搜索，发现名字，专业，系别，以及入学年份。直接高危到手（综合数据是大于2W+，除了学生还有教职工跟家长的）

五、意外惊喜之针对于CPOLAR 内网穿透服务暴露的资产。

首先了解一下CPOLAR

cpolar.top 是一个提供 内网穿透服务（类似 Ngrok）的域名。
它可以让本地服务器通过公网 URL 暴露出来，比如 xxx.cpolar.top。
这种 URL 通常是 临时的、随机生成的 或 私密的，并不会被搜索引擎收录。

ping 也是可以通的 ，微步解析IP当前都有212个域名。这台阿里云服务器可能是 CPOLAR 用户的公共网关节点，多个用户的服务通过该节点发布，多个子域名都绑定到这个阿里云 IP。也就是说，这个IP只是一个 中转点或反向代理，通过 NGINX、CPOLAR 客户端或其他反向代理处理连接。这些子域名（例如 xxxxxxx.cpolar.top）只是使用者临时、私密、个人部署的服务.

简单来说就是：xxxxxxxx.cpolar.top 实际是存在的，但没有被公开引用或爬虫收录，因此搜索引擎无法搜出来，这也是 cpolar 提供“隐秘访问”的一个典型副作用。你可以访问，是因为你得到了这个链接，搜索引擎访问不到，是因为它压根不知道这个链接的存在。

这好了BB这么多，那如何对这些XX来进行信息搜集呢。

识别 IP 资产 → 哪些可能在杭州阿里云、腾讯云

看是否有域名包含关键词，你在 FOFA 或 Hunter 搜cpolar.top的子域名，如：

test.cpolar.top    很可能是测试环境
abc-nas.cpolar.top   可能是“ABC公司”的 NAS 文件共享服务

vocechat.cpolar.top          聊天服务（vocechat 是一款开源IM）
xmgk-vpn.ngrok.io           VPN暴露了，公司缩写是“xmgk”

你就可以推断出：
哪些是测试系统（test.）
哪些是核心资产（vpn.、admin.）
哪些可能属于目标单位（根据拼音缩写、公司、学校、单位名）

CT Logs + DNS 被动解析 → 找隐藏子域名

找出那些未公开、但已经通过 SSL/TLS 使用过的子域名（哪怕短时间内用过）

ip="xx.xxx.xx.xxx" && domain=".cpolar.top" 你能查出所有被动DNS收录过的子域名

https://crt.sh/?q=%.cpolar.top
https://dnsdumpster.com/
https://virustotal.com→ 输入域名，查看子域、证书历史、链接传播路径等
certspotter,censys.io

接着就是构造字典爆破潜在的穿透子域名

好了，暂时说这么多了，不知道各位同学觉得我是否说得明白。。。

很好，年轻人，我非常看好你，既然如此：

那么以后高危的部分我就放心交给你了！

继续来看案例吧：收获意外惊喜

六、如何捕捉网络资产暴露面收敛的漏网之鱼

其实这个站我白天就踩好点了，到晚上12点左右开始到凌晨1点多提交折腾了一个多小时，

为什么这么久？且看我娓娓道来：

还有为什么要等到了晚上凌晨12点左右才开始动作，那肯定是：

信息收集打点的时候发现，首先发现是一个IP但是纯IP对应又没域名，更别说ICP备案了。

我在登录后发现该系统的用户是与某省厅的单位还有学校等，高度相联。于是我

对title标题跟icon图标来一波筛选，最后发现：

有三个IP，title标题一样，web.icon图标一样（证明都是一套框架）

我都依次点开，跳转url发现只有ICP备案的IP打开后的网站内容不一样，但是经验告诉我，应该有东西

我直到点开云IP站点，进入该系统后，思路就开始确定下来了。

3万学校管理，300+用户管理员我就知道，就是这味儿了。

但是又遇到一个问题，该系统显示的学生数据为0，而且如果你要提交漏洞的话，除了证明到敏感数据泄露或者对系统安全造成危害之外，肯定也要证明单位的归属。到这里的话，换做是你：没有看到数据又证明不了单位，你是否会直接放弃了呢？  但是我的经验告诉我，没有这么简单，肯定有东西。

到这里我一直在点击各种功能选项，只要能点击的，我都点击一遍，直到点击那个合计之后（后面再点击几遍其他什么选项，我真忘记了..........）然后就看到数据筛出来了。

当时粗略算了一下数据大概25-30W这样

（这里真的是要仔细哇）

学前、义务教育、中职、本专科、研究生每个功能模块都有数据（从幼儿园到大学研究生）这里由于太过敏感，我全部都打厚码了，截图只放部分模块，请谅解。

单单一个本专科模块就有87000+学生

到这里其实还有一点就是，所有的数据，身份证号码以及手机号码等等，都是做了脱敏处理，这时候，

"idCard": "3xxx**********xxx8"
"studentCode": "LGxxx3**********xxx8"

我在做测试的时候发现

这些值已经是脱敏后的响应内容，说明：
后端在接口响应前对这些字段做了数据脱敏处理；
* 是在后端拼接响应 JSON 时就已经存在的字符，不是前端处理结果，也不是加密后的密文；
拿到的已经是“看不见中间”的数据，渗透过程中无法还原除非有权限查看原始数据源（数据库、未脱敏接口等）。

测试脱敏控制参数，尝试给接口加一些“开关参数”：

?desensitize=false
?mask=false
?noMask=true
?debug=true
?fullData=true

或者 POST 请求体中增加：

{
"pageNum": 1,
"pageSize": 10,
"desensitize": false
}

尝试查看详情页接口，分页接口为节省流量会脱敏，但详情页接口常常返回完整字段。

分页接口如下：为了脱敏，我就替换成xxxx了

GET /specialcxxxxxxx/noSpxxxx/queryPageClick

猜测存在：

GET /specialcxxxxxxx/noSpxxxx/getById?id=xxxxx

或者：

GET /student/detail?id=xxx

这些都可以试试，如果不行，再尝试 fuzz 以下参数看是否能获取未脱敏数据：

小版本 fuzz 字段尝试：

{
"desensitize": false,
"mask": false,
"fullData": true,
"debug": true,
"exportType": "raw",
"role": "admin"
}

第二种：

{
"pageNum": 1,
"pageSize": 999,
"desensitize": false,
"mask": false,
"fullData": true,
"debug": true,
"exportType": "raw",
"role": "admin",
"noSponReason": -1,
"academicYear": "2024-2025",
"semester": "2"
}

有些系统前端不会发送 desensitize: false，但后台会识别这个字段。
有些系统根本不会验证你是否“有权限”请求未脱敏数据，只要你加了字段，它就真返回了。
所以这是一种典型的 接口设计缺陷导致的数据权限绕过。当然了，其实也有很多组合的fuzz，但是这个就是要具体结合实际情况来定义了。

以上测试其实具体还是在于数据脱敏的位置。

响应层脱敏（View 层） 有 很大机会 用 desensitize=false 等字段绕过 
服务层 / DAO 层脱敏（逻辑层或SQL层） 几乎没法绕过，请求已经取不到原始数据 
数据写入时就被脱敏 完全无法恢复原始值（只能查数据库）

我无法确定脱敏发生在哪一层，所以只能通过 fuzz 的方式去黑盒探测。但是都失败的话只能证明：

可能后端在 Service 层或 DAO 层就已脱敏
或系统默认查的是视图（view），不包含敏感字段，或者系统设计比较严谨，字段控制统一由后端决定

但是总体结果测的我：

算了，干脆打直球吧。直接来测试：SQL 注入、RCE或上传（getshell）

主要的有些困意了，现在凌晨一点这个时间也确实有点晚了。

然后试了半个小时，没弄出什么真东西。。就干脆写起报告去了。。。。

这里资产证明，就是测系统的时候有个发短信功能存在逻辑漏洞的，通过这个逻辑漏洞我转到发到自己手机号上，最后手机短信收到的是是XX智慧教育平台。

直接拿url去查ICP备案发现是：教育部教育技术与资源发展中心（中央电化教育馆）

那就直接确定归属了。

凌晨一点多提交报告之后，早上9点多审核员去复现发现，站点已关闭......

应该是我做测试的有些动作太明显，被监测到了。应急得很快哈.......

附言

本文章仅用于网络安全技术研究与合法授权环境下的学习交流，旨在增强信息安全意识、提升防御能力，不构成对任何攻击行为的鼓励或支持。本文不支持、不宣传、不引导任何形式的网络攻击行为，亦不为非法用途提供技术帮助。文章所涉技术、工具或方法仅限于教学与研究用途，严禁用于未授权的实际环境操作。最后倡导以攻促防、依法研究、技术向善。

参考文章：

CNVD EDUSRC 挖洞技巧三部曲分析（一）| 赏金猎人