漏洞某站点存在未授权访问漏洞

漏洞编号没来得及记录，漏洞但那个站点的某站IP地址我到现在还记得——203.0.113.45。那是点存洞一个市级政务系统的数据交换平台，对外开放着8080端口。未授问漏我用浏览器直接访问，权访页面弹出了登录框。漏洞然后我随手改了URL路径，某站在末尾加上/api/v1/user/list，点存洞回车。未授问漏JSON数据像倒豆子一样涌出来，权访姓名、漏洞身份证号、某站手机号、点存洞家庭住址，未授问漏整整两万三千条，权访连个遮羞布都没盖。

这不是什么高深的渗透技巧。没有SQL注入，没有暴力破解，甚至连弱口令都没试。纯粹是开发人员把接口权限校验写漏了。最讽刺的是，这个平台的安全等级保护测评报告刚通过三个月，测评机构还给了“良”的评价。

这类漏洞在政务系统里比想象中普遍。去年我顺手测过几个地级市的公共资源交易平台，十家里有六家存在类似问题。有的把投标人信息直接挂在静态页面下，有的在JS文件里泄露了内网API地址。很多甲方觉得“只要登录框够结实就行”，却忽略了后端接口才是真正的后门。

具体到这个站点，问题出在Spring Boot框架的注解配置上。@PreAuthorize只加在了Controller类头部，但部分方法用了@PostMapping却忘了继承类级别的权限控制。开发环境测试时一切正常，因为测试账号有管理员角色。部署到生产环境后，这个疏漏就像忘了锁的侧门——正门再气派也没用。

我按流程提交了漏洞报告，对方安全负责人的第一反应是“不可能，我们扫描过”。我把浏览器截图甩过去，对面沉默了几分钟，然后回了一句：“能帮我们确认下影响范围吗？”那语气跟之前判若两人。

修复过程也值得一说。他们没改代码逻辑，而是直接在Nginx层加了IP白名单。这种临时补丁治标不治本——换个代理IP照样能访问。后来我提醒他们，真正的修复得在方法级别补上权限注解，或者统一走网关鉴权。过了两周再看，接口返回了401，这才算完事。

这案子让我想起另一个体检系统的漏洞。那边更离谱，未授权访问直接可以查看体检报告PDF，连加密都没有。问起来说是“内网部署，外网访问不了”，结果用Shodan一搜，暴露在公网上的设备挂着默认口令。安全这行，侥幸心理比技术漏洞更难补。

现在很多单位做等保测评，花钱买报告，却没人真正关心代码里的逻辑漏洞。扫描器能扫出已知CVE，但像这种“忘了加权限”的毛病，得靠人翻代码或者手工测接口才能发现。我见过不少测评机构拿着工具跑一遍就出报告，连业务逻辑都没看过。

写这篇东西不是要炫耀什么。那个政务平台的数据早就脱敏了，漏洞也修复了。但每次看到类似的新闻——某医院预约系统泄露患者信息，某学校成绩查询接口裸奔——我都觉得，技术从来不是最难的关卡。最难的是让人承认“我的系统可能有问题”，并且愿意花时间去找。

后来我把这个案例写进了内部培训手册，标题就叫《别让你的接口裸奔》。同事看完说太直白，我倒是觉得，直白点好，至少比那些“加强安全意识，提升防护水平”的废话管用。