目录
一、信息收集
在搜索某大学资产时发现以下资产
某大学的大学学报，看到这里，就似乎有一种吸引力，对于这种偏边缘资产，一看就觉得有洞，果不其然还真的有啊！
二、漏洞复现
首页处有个作者投稿的功能，不得不想能投稿就一定有账号吧，有账号那就会有常见的登录框那些 漏洞，二话不说先来看一眼，大概如下：
没账号怎么办呀，先去注册一个呗！
简单注册好账号，登录后就会有更多的功能点可以测试。发现以下功能点：
可以申请为专家，那就意味着有一个参数代表着身份，不同的身份有不同的作用。当然了专家这种相对较高的权限就有更多不同的功能点可以测试，说干就干，看看申请专家需要什么？
然后紧接着对其抓包
发现并没有什么可以一眼标记专家的参数
发送后发现成功申请为专家。虽然没有什么标志性参数，但是有我们的老朋友：username，不得不尝试一下是不是也可以把别人提升为专家呀？如果可以不就构造成水平越权喽？
换个username后依旧操作成功，拿下拿下，水平越权一个！
三、总结
系统接口 /prod-api/system/user/toBeProfessor 在处理"申请成为审稿专家"业务时，仅通过查询参数 userName 指定目标账号，且仅依赖前端登录后的 JWT（Authorization/Cookie 中 Admin-Token）完成身份认证，但后端未校验当前登录用户与传入 userName 是否一致，导致任意已登录用户可将他人账号越权提交为审稿专家。
测试思路提醒：此类业务操作类接口是越权漏洞的高发点，测试时应重点关注"仅凭请求参数指定操作对象"的接口，通过替换参数值（如更换 userName）判断是否触发越权；同时需留意接口返回的 code 与 msg 语义（如"请勿重复提交"与"操作成功"的差异）来确认操作是否真正生效；测试中应使用最小影响验证，避免对他人账号造成实际修改。
修复建议：服务端应从登录态会话中获取当前用户标识，而非信任前端传入的参数，并对 userName 等参数做与当前用户身份的绑定校验，仅在本人申请场景下放行；同时建议对该类敏感操作增加权限校验与操作审计日志，防止横向越权被滥用。