文章总结： 本文记录了一次针对高校支付系统的渗透测试过程，测试者通过注册账号发现SQL注入漏洞并利用通用凭证漏洞实现多个高校系统的横向突破。关键发现包括系统存在至少6处SQL注入点及JWT令牌复用漏洞，最终实现一个token通杀十余所大学。可操作建议包括资产收集时关注通用系统特征、测试时优先检查支付类系统的凭证复用风险。 综合评分： 85 文章分类： 渗透测试,WEB安全,漏洞分析,实战经验,安全工具

一次渗透学员母校捡漏通杀？

原创

只会弱口令 只会弱口令

只会弱口令

2026年4月3日 16:16 广东

免责声明

本文仅用于网络安全技术学习与交流，严禁将文中技术用于任何非法入侵、未授权测试、数据窃取等违法违规行为。因擅自使用本文内容进行非法操作、或传播本文所造成的一切法律责任与经济损失，均由使用者自行承担，与本公众号及作者无关。如有内容侵权，请及时联系我们处理

前言

当时学员还以为我早就挖过他母校的洞了，结果并没有。既然如此，那必须带着学员狠狠干一波。毕竟，没测过自己母校的漏洞，人生总感觉少了点什么。

测试过程

1.资产收集到一个某支付平台，可正常注册账号，因此直接注册一个测试账号，避免后续再次花时间收集可用账号。

2.注册进去之后，先把能点的地方全点一遍，顺手看看有没有信息泄露、SQL 注入这类常规洞。

结果你说巧不巧，缴费查询这个功能点，就感觉这地方大概率有 SQL 注入。大概如下

year=' --报错year='' --正常

小小SQL注入直接塞入大大payload，拿下当前用户长度，达到edusrc测试SQL注入标准

这就结束了吗？那肯定不可能，一个系统一旦暴露出 SQL 注入问题，意味着系统肯定还会在其它功能点存在SQL注入。

后续也找到了5处SQL注入点，不过edusrc同一个站点不同接口SQL注入只收3个。

因为支付类的系统一般大概率是一个通用的系统，通过查询icon也只有几个资产。

这里也可以使用系统标题搜索其它单位资产，这里是智慧财务，找到对应厂商

找到其它单位资产剩下就可以一一测试了

在我为此高兴的的时候，万万没想到，测试了几个单位都没开放注册接口，这不玩了吗？通杀的好机会，上大分的好机会就这么没了？

灵机一动，拿之前的jwt在其它单位使用，不是哥们？真可以？？？？

没想到意外捡漏，竟然存在通用凭证漏洞。最后就是一个token通杀10几所大学。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：只会弱口令 只会弱口令 只会弱口令《一次渗透学员母校捡漏通杀？》