NewAPI 这个 bug，可能正在“悄悄掏空”你的额度漏洞线报

RunaCase
RunaCase
RunaCase
管理员, Keymaster
私信
5830
文章
2
粉丝
渗透测试评论2字数 1632阅读5分26秒阅读模式
今天看到一条提醒，信息量不大，但后劲很足：
newapi 出 bug 了，各位自己去查日志。image 生图功能建议先关闭。
为什么要先关？
因为用户可能通过传入特别大的参数，比如 n 图片数量、duration 视频秒数、max_tokens 等，让系统在计算额度时发生异常。
最要命的是：
quota 计算整数溢出，可能变成负数，最后不是扣额度，而是把额度反向冲进用户 credit。
说白了，这不是普通的“小显示错误”。
如果情况属实，它可能直接影响你的成本、余额、风控和账务。

一、发生了什么？

从截图里的描述看，问题集中在一个点：
用户输入的参数过大，导致额度计算超出系统可承受范围。
比如生图接口里，用户可能提交一个极大的图片数量 n；视频任务里，可能提交一个极大的 duration；文本接口里，可能提交一个极大的 max_tokens。
正常情况下，系统应该判断参数是否合法，然后按规则扣费。
但如果参数没有被严格限制，后端又直接拿它参与 quota 计算，就可能出现整数溢出。
结果就离谱了：
本来应该扣 10000 点额度，系统一算，变成了负数。
负数再进入扣费逻辑，就可能等于“反向充值”。
这类 bug 最可怕的地方，不是它看起来复杂，而是它一旦被人发现，利用门槛可能并不高。

二、为什么建议先关 image？

因为生图接口天然更容易被“放大参数”。
文本接口的 max_tokens 虽然也危险，但很多模型服务商、网关、SDK 本身会有限制。可生图接口里的 n，如果系统没有前置校验，就可能被传一个非常夸张的数字。
而图片生成的成本通常又比普通文本更高。
也就是说，image 一旦被打穿，损失会更明显。
所以这条提醒里说“image 生图需要先关闭”，不是小题大做，而是一个非常现实的止损动作。
先关掉高风险入口，再查日志、补校验、修账务，这是比较稳的处理顺序。

三、真正危险的不是 bug，而是“账务系统信任了用户输入”

这个问题背后，其实是很多 API 网关、聚合站、AI 中转系统都会踩的坑：
把用户传来的参数，直接当成可计费依据。
用户说要生成 999999999 张图，系统就拿这个数字去算。
用户说要 999999999 秒视频，系统也拿去算。
用户说 max_tokens 巨大，系统也先进入计算流程。
但在计费系统里，有一个原则必须非常硬：
所有来自用户的数字，都先是假数据。
它必须经过三层处理：
第一，类型校验。
是不是整数？是不是正数？有没有小数、字符串、科学计数法、空值绕过？
第二，范围校验。
图片数量最多几张？视频最多几秒？tokens 最多多少？不同模型是不是不同上限？
第三，安全计算。
即使前面校验过，后面参与金额、额度、credit 的计算，也不能用容易溢出的类型，更不能让负数额度进入扣费或充值逻辑。
很多事故不是因为黑客多强，而是因为系统太相信“正常用户不会这么传”。
可互联网产品最不能相信的，就是“大家都会正常使用”。

四、管理员现在应该立刻做什么？

如果你正在用 newapi，或者基于类似项目搭建了 AI 中转服务，建议马上做几件事。
第一，先看日志。
重点查最近有没有异常大的 n、duration、max_tokens。
尤其是生图请求、视频请求、长文本请求，以及额度变动记录。
第二，先关高风险能力。
如果你没把握是否已经修复，就先关闭 image 生图，或者至少限制生图模型、限制并发、限制单用户调用次数。
第三，检查 credit 变化。
重点看有没有用户余额突然增加，或者某些请求之后余额不是减少而是增加。
如果出现这种情况，基本就不是普通 bug 了，而是账务被污染。
第四，给所有参数加硬上限。
不要只依赖前端限制。
后端必须限制。
模型层必须限制。
计费层最好也再兜底一次。
第五，扣费逻辑里禁止负数流入。
任何 quota、cost、credit_delta，一旦出现异常负数，都应该直接拒绝、告警、写日志，而不是继续执行。

五、这件事给所有 AI 产品的提醒

AI 应用现在有一个很大的变化：
过去的软件 bug，可能只是页面报错。
现在的 AI 产品 bug，很多时候会直接变成钱的问题。
因为每一次调用背后都有真实成本：token 成本、图片成本、视频成本、代理成本、队列成本、带宽成本。
所以，AI 产品的安全重点不只是“模型会不会乱答”，还包括：
参数会不会被放大，成本会不会被击穿，账务会不会被反向利用。
尤其是做中转站、聚合平台、API 分发、额度售卖的人，一定要把“计费安全”当成核心模块，而不是附属功能。
再小的计算错误，只要和余额挂钩，就可能变成大漏洞。

六、最后判断

目前这条信息来自截图提醒，细节还需要各位结合自己的部署版本和日志确认。
但就算你还没发现异常，也建议先按高风险处理。
因为这类问题的特点是：
没被利用时，它像一个小 bug；一旦被利用，它就是一笔账。
如果你是管理员，今天最该做的不是继续观望，而是马上查三样东西：
日志里有没有超大参数。
账务里有没有异常 credit。
生图和视频能力有没有硬限制。
先止血，再修复。
先保护余额，再谈体验。
这次 newapi 的提醒，本质上不是一句“项目出 bug 了”。
它是在提醒所有 AI 产品开发者：
AI 时代，最贵的漏洞，往往藏在一个没有限制的参数里。

相关阅读

 
  • bug
  • 并发
  • 渗透测试
匿名

发表评论

匿名网友
确定

拖动滑块以完成验证