某企业网关代码审计

写在前面

这个某企业不用我说也知道是我待过的公司了，但是不会点名的

以下都是情节模拟，并非具体情况，请细加甄别

在24年初，公司让我和阿里的安全人员对公司资产做了一些渗透工作，我们发现的问题不少，也有相互重合的部分，其中对于验签的问题，在 有点问题：灰产-如何破解请求验签（上） 及 有点问题：灰产-如何破解请求验签（下） 已经有过表述

那么，隐藏在验签下的问题有什么呢？

我们同时在不同的接口上发现了大小的越权问题，例如可以看到别人的收货地址等，但只是在接口层面的，没有意识到可能是一个大范围的问题，直到一个疑惑在我的脑海里萌生——

“为什么我们的 userid 有这么多的写法呢？”

好奇是所有问题的开端，害死了无数牛马（x

所有起因

因为那时我来公司不久，阿里安全人员又是外来做服务的，都无法解答这个问题，后来才知道是因为在2017年的时候公司做过技术迁移，从 Php（没错，就是如此古老）转到 Java，而后在2022年又进行过一次升级改造，现在已经是第三版了，所以代码的入参字段会有历史遗留，但由于一直都在用，也没有机会和足够的理由进行 C端强制升级，也没有足够的人力去投入，毕竟业务需求第一嘛……

我只能说，一般有这种想法的公司不改的话，迟早有一天会爆个大的

如何触发

其实非常简单，也就是在测试增加错误字段的时候，我们好奇地想，如果采用不同的userid书写方式作为字段，在 body 中发起 api 请求，会怎么样？

他妈的下面的userid字段可以覆盖上面的userid字段，并直接被后端服务作为正确入参而调用！

How Can It Be！

尝试了几个接口都可以被如此利用后，直觉告诉我，不可能是后端各式的应用服务做了这样的解析和取参，应该是网关层面的问题，遂查之

在撸了一串人后，我们确定了这个问题是17年那次迁移时，为了兼容老旧 Php 实现，然后在22年迁移时，为了兼容老旧 Java 实现引入的两段代码导致的，直接人员早就离职了

这段代码会在读取到旧的 userid 字段后，自动放弃掉新的写法，不从 token 中解析 userid，直接信任用户传入的字段值……

危害程度

直到这里，大伙还是“这个问题都存在7年了，又没发生大问题，你来就要说改，就要翻天了？”

我表示，好像确实还没有找到被利用的痕迹，我现在数据不完整，我 SLS 上捞一下现在有哪些接口还是这样的类似实现，然后我再一个个给你们验证好，是不是都可以触发这个问题，在告诉你们能造成多大的危害，我们再来谈要不要改的问题

我不知道这种问题是不是安全人员做，但是完全由安全梳理验证和评估应该是不合适的，但我还是一个人做了，给他整完

结果就是：自2024年Q4末期到2025年Q1，从网关配置（compatible.before.dubboApiStr.生产配置）导出PHP相关老旧接口130例，再由网关日志（xx-gateway_xx-gateway）30天流量匹配出PHP相关老旧接口76例，审查得到越权查看修改个人信息、过度返回信息（token、API、部分源码）、伪造进行业务操作（取消任意用户预约排队乃至无需权益进行开门）等问题，以下为细节问题划分与处理方案……

后续处理

当我把这些细节展示出来，并且反馈上级时，得到的是各TL“我们都知道这个地方有问题啦，有处理方案，就是没人推巴拉巴拉”，然后CTO是一句“下次这种大家都有方案达成共同认知的问题就可以不用拉我，你们去推进做就好了”

不是，如果我不去统计，我不去挖不去审计，你们真的知道这会引起什么问题，怎么引起，又是因为什么代码引起的？你们知道有哪些要改，会影响到哪些业务，哪些需要下线需要换新接口，哪些可以直接在原有基础上改网关代码就能兜底？

这个问题从24年初被发现，到25年Q3才被从网关上兜底解决，而且解决了也被觉得是个7年都没发生问题的问题，解决与否感觉没什么价值，我并没有受到任何肯定，大家也只是觉得是安全强要求才推进去做的