漏洞挖掘—简单的逻辑漏洞（通杀）

最新推荐文章于 2026-03-25 00:00:24 发布

原创最新推荐文章于 2026-03-25 00:00:24 发布 · 650 阅读

14 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#安全 #web安全 #网络

漏洞挖掘—简单的逻辑漏洞（通杀）

前言

上次更新之后又是过了很久没有再写过通杀漏洞了，而最近也是运气比较好，挖掘了一个新的通杀漏洞，顺便这个通杀漏洞还拿下了两个证书站，今天写出来与大家分享一下思路。

其实漏洞是一个很简单的漏洞，但是发现这个功能点辗转了多个网站，又不能虚空找功能点，所以这篇文章主要还是记录了一下发现的过程。

一、发现查询功能点

故事的一开始，是我想挖掘证书站漏洞，某位大佬知道后甩给了我一个挖掘出过SQL注入的站点（原功能点已修复），让我再尝试一下，看其他功能点会不会存在相同问题。而且站点确实很老了，很像有漏洞样子，奈何自己太菜，研究了一晚上也没发现新的漏洞。

但是在挖掘过程中发现了该站点的某个接口下泄露了完整的学生sfzh等信息，虽然只泄露了该账号学生的信息，但这个其实在EDU SRC中也是算漏洞的（低危1rank），不过这里我没交，因为实在没什么用。

无奈，既然都已经都已经开始了，肯定不能放弃，只能重新收集这个院校的资产，继续进行测试。

依旧运气不错，很快就有了新的发现，在某缴费平台的重置密码处发现只需要学生的学号、姓名和sfzh就可以重置密码了。这不前面刚刚拿到了一个sfzh信息，马上拿来试一下，成功重置密码，进入系统。

这次进入后获取了更多详细的身份信息，但这个系统本身的功能点少的可怜，依旧没有什么收获。不过在我观察了每一个功能点后发现了一个有意思的地方，在点击“电子票”后会直接跳转到另一个“电子票据平台”站点的查询功能处，只要提交证件号码和交款人姓名就可以查询票据。

二、越权查看票据信息

同样是利用前面获取的sfzh信息和姓名进行查询，发现可以获取到学生的票据信息，而且这个查询接口竟然是GET传参的，本身接口也不需要进行登录就可以使用，这就存在了很大的操作空间。

参数大概是下面这样的，可以用deepseek简单的分析一下。

billType=0&payerIdType=1&payerIdNo=3700002000101014321&payer=张三&billTypeName=财政票据

既然有这么多查询参数，那当然是要测试一下是否存在注入点的，在每个参数后都加入单引号，尝试闭合语句进行测试。当我在**“payerIdType”参数后加入单引号时，发现返回了更多票据信息（起初我以为这个参数是存在注入的，但通过后面测试发现其实不是，需要记一下）**。

但这里就有一个很有意思的点，当我只在**“payerIdNo”**的参数后加入单引号时，会产生报错“查询无数据，请稍后再试”。

而如果我同时在**“payerIdType”和“payerIdNo”两个参数后都加入单引号时，数据是正常返回的。后面我直接将“payerIdNo”的参数删除后发现依然正常返回数据。那这就很明显了，如果此时sfzh数据是无效的，那传递的参数信息中只有“payer”**参数，也就是姓名能进行鉴权了。

想到这里我直接搜集该院校学生姓名，更换之后成功越权查看了其他人的票据信息。而这里我前面的文章也提到过个人的“统一社会信用代码”其实就是sfzh，翻看票据后发现有部分票据只打码了后四位，而又有部分票据只保留了后四位，拼接后刚好获取了完整的sfzh信息，获取学生敏感信息。

到了这里就又和前面的系统形成了闭环，获取了完整sfzh信息后，拥有学号和姓名可以重置系统密码，接管大量学生账号（这个不是通杀，只是在这个院校可以）。

然后我们再回到刚开始使用单引号闭合的时候，刚才说了，起初我是认为存在注入的，当然还是要再测试一下是否真实存在注入。但多次尝试后发现无法注出数据，这就很奇怪，明明也没有什么防护，后面我无意间输入了一个“?”发现也与加入单引号效果相同。又经过了多次尝试，加入各自字符后，破案了，这里根本不是什么闭合，只要输入无法检测的参数，都会导致后面“payerIdNo”不再校验。（吐槽一下，这逻辑就很奇怪，真不知道后端是怎么写的）