技术分享-edusrc入门及相关案例分享
edusrc入门经验及相关案例分享
前言
本文是我在校内实验室的技术分享内容。
本次分享算是对自己前段时间摸索出来的挖edu的思路的一些总结以及希望帮助到各位入门的朋友有一个大概的思路。为什么想到讲这个呢?edusrc相对其他的项目来说较为简单入门,所以前期可以拿来练手练技术,提升思路。
主平台:
一个聚焦教育行业的第三方漏洞报告平台
注册的话需要先挖到一个洞或者需要一个邀请码。
这里我主要不是去讲如何在单个漏洞绕过的复杂技巧,而是想把 edusrc 入门的一条更实际的路线/思路串着讲出来:先想办法拿到账号或者进入系统,再通过低权限账号不断扩大攻击面或者配合高权限账号测试越权,最后根据指纹去关联同类站点。
一、第一步往往不是挖洞,而是先想办法进入系统
在 edu 场景里,很多系统不登录根本看不到核心功能。所以相比一上来就盯着某个参数,不如先解决一个更现实的问题:怎么拿到账号,或者怎么先进系统。
1. 信息收集先做全
先收集资产,再收集能帮助登录的信息,比如学号、工号、手机号、身份证号、邮箱、教师编号、系统使用手册等。
常见的一些 Google 语法:
site: xxx.edu.cn "学号"
site: xxx.edu.cn "身份证"
site: xxx.edu.cn "工号"
site: xxx.edu.cn "关键字" && (filetype:pdf OR filetype:xlsx)
这类信息经常会出现在通知、附件、名单、公示、操作手册、历史页面里。有些文档可能也会直接写出某个系统的默认密码。
一个好用的工具:Fir-Fetch,一键收集公开学号、工号、邮箱等信息。
github信息收集
通过相关语法去搜索源代码中可能暴露的明文账密。
原因?
很多学生可能会把自己做的用到学校相关系统的项目放在github,没有对明文密码进行处理。
2. 资产收集决定你能不能找到入口
空间测绘这一步很重要,因为很多可利用点根本不在主站,而是在二级域名、老系统、边缘业务系统或者历史遗留平台上。
我平时比较常用的一些 FOFA 思路:
org="China Education and Research Network Center"
icon_hash=""
domain="xxx.edu.cn" && body="登录"
domain="xxx.edu.cn" && body="注册"
org="China Education and Research Network Center" && (body="忘记密码" || body="找回密码" || body="注册")
如果是单独打一个学校,也可以按这个路线来:
搜索引擎拿主域名 -> 查 IP 和网段 -> 按网段去扩资产 -> 回头筛带登录框/注册/找回密码的系统 -> 查询备案号的其他域名,重复该流程
核心思路其实就一句话:先尽可能把“能进系统”的入口找出来。
这里以本校为例,展示如何快速配合fofa + ip138 拿到大部分资产,以及如何筛选出相对有攻击面的。
为什么不只用domain去搜? 有些资产可能没有挂域名,但是在网段内,且很有可能是相对脆弱的资产,这样我们就可以手机的全一些。
3. 指纹收集会直接影响后续打法
浏览器插件比如 Wappalyzer 很适合做第一轮指纹识别:

指纹信息最直接的价值在于:
- 能判断框架和组件,看看有没有现成的中间件或框架 Nday 可以打(有现成的集成利用工具)。
- 能判断开发语言,进而推测数据库类型和后续漏洞利用方向。
- 能判断是否值得重点关注上传点、富文本点、历史接口和后台路径。
举几个很实用的联想:
- 看到
ThinkPHP、SpringBoot、某类老中间件,第一反应就是去看有没有对应 Nday。 - 看到站点是
PHP,而且还能上传文件,就要额外关注能否从上传走到代码执行。 - 如果遇到 SQL 注入,开发语言和站点指纹常常能帮助你更快判断数据库大致类型,比如
ASP.NET常见MSSQL/Access,PHP常见MySQL,Java很多场景会落到Oracle。
二、面对登录框时,可以按这个顺序去试
很多时候我们我们刚开始总是会被困在登录框上,如何突破登录框进入系统是我们主要要做的内容。
下面这 7 个方向基本可以当作速查表:
- 弱口令/默认密码 (123456 admin123 12345678 test/test)
- 查看操作手册、通知文档、公开附件是否泄露了账号规则
- 测试万能密码、报错、SQL 注入相关特征
- 观察并尝试逻辑绕过,尤其是返回包和状态码
- 找注册、找回密码、短信验证、邮箱验证这些外围功能
- 看看能不能访问到后台登录页面,再重复一轮测试
- 顺手测未授权接口,别把注意力只放在登录动作本身
1. 弱口令和默认密码永远值得先试
这一步虽然朴素,但在 edu 场景里并不过时。尤其是一些内部管理系统、移动端接口对应的后台、二级学院自建系统,密码质量并不稳定。
如果遇到明文传输的,就可以尝试直接字典爆破。
如果传输的账密信息被加密,则涉及到了js逆向(暂时没学到)。
2. 用户名枚举经常能帮你补齐前置条件
如果登录接口会明确回显“该用户不存在”这类信息,就可以借此判断用户名是否有效。用户名一旦确定,后面无论是弱口令、默认密码、密码重置还是逻辑绕过,成功率都会高很多。
3. 返回包逻辑绕过不要漏
不少系统校验做得很浅,前端或中间层只认一个布尔值、一个状态码或者一个固定字段。
常见观察点:
true/falsesuccess/fail0/1- HTTP 状态码
- 登录成功后返回的 token、role、permission、menu、deptId 等字段
如果一个流程本来就设计得比较草率,那么问题未必只在登录动作本身,找回密码、绑定手机号、短信校验、邮箱校验这些位置同样可能有绕过空间。
4. 把外围功能一起看掉
除了登录框本身,下面这些地方经常更容易出问题:
- 注册功能
- 重置密码/忘记密码
- 验证码校验
- 短信发送接口
- 邮箱验证接口
- 第三方单点登录绑定流程
特别是注册功能,如果没有人工审核、身份校验薄弱,往往能非常快地拿到一个真实可用账号。很多测试卡在“进不去系统”,本质上就是没有把外围功能一起看。
注册的时候身份信息可以用网上一些专门生成的虚拟信息的站点来填,邮箱接码等。
最常见的进入系统的方式: 弱口令+有注册功能的站。
5. 一些好用的辅助插件
findSomething 这类插件很适合顺手找接口、找路径、找前端暴露出来的资源:

面对资产很多的时候,Open Multiple URLs 这类批量打开站点的插件也能明显提高效率。
vuecrack

burp中的HaE插件 能帮我们通过正则匹配识别到一些敏感信息。
三、进入系统之后,攻击面会明显扩大
一旦有了账号,哪怕只是普通用户权限,很多原本看不到的接口、页面、上传点、管理动作都会暴露出来。这个阶段就不是“能不能进”了,而是“进来以后要看什么”。
1. 文件上传是最常见也最容易被忽略的攻击面
进入系统以后,优先去翻这些位置:
- 头像上传
- 富文本编辑器里的图片上传
- 证书、附件、报名材料上传
- 个人资料、作品提交、报销材料上传
文件上传常见有两条思路:
- 看能不能上传
html/svg等内容,进一步走到存储型 XSS。 - 如果站点环境本身存在解析风险,再看有没有机会从上传走到代码执行。
很多人会只盯着“专门的上传功能”,但实际上富文本编辑器往往更值得重点看,因为它经常是现成组件,限制也更松。
2. XSS 的原则很简单:见输入点就想一下能不能打
这句虽然听起来很土,但确实实用。常见位置包括:
- 富文本编辑框
- 个人信息编辑
- 昵称、签名、留言、简介
- 文件名、图片描述、备注字段
- 搜索框、反馈框、工单提交框
edu 场景里,存储型 XSS 的价值通常不低,因为很多内容会被管理员、审核人员、辅导员、教师端再次查看。一旦命中后台角色,影响面会比普通站点更大。
3. SQL 注入依然是值得长期关注的点
登录前后都可能遇到 SQL 注入,但进入系统后参数更多、功能更复杂,命中率往往会更高。
我比较关注的几类位置:
id、newsId、articleId这类展示型参数- 查询类功能,比如学号查询、成绩查询、信息检索
- 排序参数,比如明显带有
asc、desc、order特征的接口 - 隐藏在异步请求、分页请求、二次加载请求里的参数
例如一些很典型的注入场景:

万能密码


这里一个很重要的习惯是:每拿到一个注入点,就立刻结合站点指纹去判断数据库类型。
这样方便你之后就能去结合数据库类型去fuzz有哪些能够利用的冷门函数去绕过。
很多时候,报错信息、函数特征、开发语言、页面框架这几条线一合并,后续测试路径会清晰很多。
4. 越权是普通用户阶段最容易出成果的方向之一
进入系统之后,一定要重点看越权,尤其是下面这几类:
- 水平越权
- 垂直越权
- 未授权访问
重点关注的东西通常不是很复杂,反而都很朴素:
-
userId -
id -
uid -
deptId -
roleId -
studentId -
teacherId -
资源编号、订单编号、申请编号
有时候也不一定是参数,比如 /prod-api/api/user/getById/2

垂直越权也不只是在接口里找“管理员专属动作”。普通用户登录成功后返回包里的鉴权字段同样值得细看,例如:
role: adminisAdminpermissionmenuCodedataScope
很多时候不是接口本身在裸奔,而是前端把关键权限字段暴露得太多,或者后端根本没有做严谨的二次校验。
5. 图片和文件的存储方式也要看
如果系统里的图片、附件、头像、富文本资源走的是对象存储,比如 OSS、MinIO 之类,那就不要只把它当普通静态资源看。
重点关注:
- 存储桶能不能遍历
- 是否存在敏感文件泄露
- 上传后的资源是否可控
- 桶权限是否异常开放
下面这种就是很典型的桶遍历场景:

如果遍历出来的是名单、证件照、导出文件、配置文件、历史备份、Excel 附件,那价值会非常高。
有些场景里,错误配置甚至不只是“可读”,还可能进一步扩展到上传、覆盖或删除对象。这个时候影响就不再只是信息泄露,而是能直接进入到更主动的利用阶段。
还有一种很实用的思路是把上传和对象存储结合起来看。比如原本只是“能传一个文件”,但如果文件落在可直接访问的对象存储上,又能控制响应内容类型,那就可能进一步转成 XSS 风险:

四、如何从单点问题扩展到同类站点
很多时候,一个洞的价值不只在这个站本身,而在于它背后对应的是不是一套模板、一套供应商系统、一个学院里复制出来的多套站点,或者一批相同指纹的资产。
所以我的习惯是:每当挖到一个洞,就立刻反过来提取这个站点的指纹。
1. 挖到洞之后,第一时间记这些特征
icon_hash- 页面标题
- 登录页文案
- 特殊接口路径
- JS/CSS 资源路径
- 页脚版权信息
- HTML 注释
- 报错信息
- 接口返回格式
- 特有字段名、参数名、Cookie 名
这些东西单看可能不起眼,但组合起来往往足够把同类系统搜出来。
2. 多看相似指纹,而不是只盯一个站
比如下面这些都很适合拿去关联排查:
- 相同图标
- 相同登录页样式
- 相同源码里的特殊字段
- 相同的上传路径
- 相同的报错页面
- 相同的前端框架特征
如果一个站的洞来自某个老旧组件、某个供应商模板、某种固定开发习惯,那大概率不会只出现在这一处。
3. 思路上的关键不是“通杀”,而是“同类资产联动”
“通杀”这个词很多人爱说,但真正实战里更重要的其实是:你能不能快速判断一个问题是不是同类系统共性问题。
一旦确认是共性问题,后续就可以按下面这个顺序推进:
- 先确认漏洞是代码问题、配置问题还是部署问题
- 再提取能用于检索的指纹
- 然后去同类资产里做关联验证
- 最后把结果按学校、系统、供应商、业务线分组整理
这样做的好处是,你不是在一个站上反复打转,而是在用一个点撬动一批相似目标的排查效率。
这里以一个实战案例为例。

进入之后发现这里的打印简历功能:

点进去会发现存在一个resumeId字段,尝试单引号之后返回了403,两个则正常返回。
后续绕过提交之后就在想这种系统会不会很多学校在用,于是通过网站图标fofa上搜到了一部分,

后来想想可能这样搜的不太全,于是想到了通过网页上的一些特殊代码片段可以定位:


明显更多了。在之后又发现了一个更具标志性的参数字段在html中,且很明显是这个系统独有的参数:


这比之前多的多,由此可见:指纹找的足够准确,能够通杀的则会越多。
注意:拿到符合cnvd之类的通杀可以先交。
五、最后总结
如果把整条路线压缩成一句话,那就是:
先想办法进入系统,再围绕低权限账号扩攻击面,或者进的是高权限,尝试再拿到一个低权限测越权,每出一个洞就回头提指纹,最后把单点问题变成同类系统问题。
我自己的习惯大概是这样:
- 先收集资产,优先找能登录、能注册、能找回密码的入口
- 遇到登录框先按固定顺序测,不乱打
- 进入系统后优先翻上传、富文本、查询接口、个人中心和对象存储
- 每发现一个问题都顺手判断开发语言、数据库、组件和部署特征
- 发现问题后不要只盯当前站,立刻去搜相似指纹
关于平时的积累,可以多看看相关大佬每天发的公众号实战文章拓宽一下思路。
希望本次的分享能够对各位入门/即将入门阶段的同学有所帮助,思路顺了,基本上是时间问题。

浙公网安备 33010602011771号