我的 SRC 第一滴血。已按平台规则脱敏：不出现厂商/学校名、接口路径与密钥本体，只讲思路与方法。
背景
目标是某高校的一套线上业务系统（教育行业 SRC 公开范围）。那段时间我在练信息收集和前端 JS 审计，抱着”练手”的心态开始对公开资产做攻击面梳理。
发现过程
- JS 审计：翻前端打包产物，逐 chunk 找硬编码的密钥、内部接口和敏感注释。
- 异常接口：发现一个与短信服务相关的接口，未登录即可访问，且响应里返回了一组疑似短信服务商的平台凭据（AppKey/AppSecret 形态）。
- 确认敏感：这类凭据用于调用短信通道发送验证码/通知，泄露意味着攻击者可冒用该单位名义发短信（钓鱼引流、消耗短信余额）。
无害验证
这是我自己死守的红线，我只做了这些：
- 确认接口无需任何认证即可访问（普通 GET，无 Cookie/Token）。
- 确认响应中的凭据格式真实有效（与短信服务商文档的凭据结构比对）。
- 没有调用任何发送接口、没有发送哪怕一条测试短信、没有触碰任何用户数据。
证明”凭据能被任意匿名用户获取”这个事实本身，就足够构成漏洞。
提交与审核
- 报告结构：漏洞描述 → 复现步骤（请求/响应截图，密钥打码）→ 危害分析（冒名短信、资费损失）→ 修复建议（密钥下线轮换、接口加鉴权）。
- 同批提交的其他几份报告因”只证明缺陷存在、没证明能获取到什么”被打回——这轮驳回让我理解了定级看的是实际危害证据，不是缺陷存在性。
- 这份最终审核通过（低危）——第一枚 SRC 战绩落袋。
收获
- JS 审计是 SRC 性价比最高的动作之一：硬编码凭据/隐藏接口至今仍大量存在。
- 无害验证边界感：能证明”门没锁”就够了，不需要进屋翻东西。
- 审核标准是一课：被打回的四份比通过的这一份教会我更多——证据链完整、危害写实、不夸大。
- 把每次提交当技术写作训练：复现步骤要让审核员三分钟复现。
下一个目标：把”存在性证明”升级到”影响面证明”，冲中高危。