今天要讲解的是：好靶场支付逻辑漏洞，充值舍入漏洞。说实话， 每次看到这种题目，我的心情就特别复杂，既兴奋又有点无奈，兴奋的是又能薅羊毛了无奈的是为什么这种低级错误总是层出不穷？ 实际上... 真的是让人头大。咱们今天就好好唠唠这个事儿，不整那些虚头巴脑的，直接上干货，虽然这干货可能有点馊，但绝对能吃！

到底什么是舍入漏洞？这玩意儿为啥这么坑？

舍入漏洞是财务、 支付、电商等涉及金额计算的系统中，因对小数金额的舍入规则设计不当或计算逻辑不统一导致实际金额与预期金额产生偏差，进而被攻击者利用获取非法利益的业务逻辑漏洞。 复盘一下。 这定义听起来是不是特别绕？特别官方？其实说白了就是系统在算账的时候，脑子抽了一下把几分钱给弄丢了或者多给了。这可不是小事啊，积少成多，那可是天文数字！

你想想看， 其核心成因是不同系统模块采用不一致的舍入方式，或未对舍入后的金额进行二次校验，形成金额差漏洞。这就像是你去菜市场买菜，大妈用四舍五入，你用去尾法，再说说肯定得打起来嘛。系统也是一样，前端说一块九毛八，后端非说两块，这中间的两分钱去哪了？是不是被谁给偷吃了？这就是漏洞所在！这就是我们攻击者的机会！

有时候我就在想，写这些代码的程序员是不是数学都是体育老师教的？怎么连个加减乘除都搞不明白呢？真的是让人无语。每次遇到这种漏洞，我都想给那个开发寄一块橡皮擦，让他好好擦擦脑子里的水。不过话说回来 这种漏洞虽然原理简单，但是挖掘起来还是挺费劲的，特别是那种隐藏特别深的，你得有耐心，得像绣花一样去抓包，去分析。

常见支付网关平安处理能力对比

为了让大家更直观地理解不同系统在处理这种精度问题上的差距， 我特意搞了个表格，大家看看，是不是一目了然？虽然这数据是我瞎编的，但道理是这个道理。

看看这个表格，是不是觉得“好靶场支付”特别可爱？简直就是送分题。但是现实中，很多系统其实就跟“懒人付”差不多，甚至还不如它。这就是为什么我们要学这个，为了保护自己的钱包，也为了...咳咳，为了测试系统的平安性，尊嘟假嘟？。

实战演练：好靶场里的那些破事儿

好了 废话不多说咱们直接进入正题。今天要讲的就是这个“好靶场”里的充值舍入漏洞。说实话，这个靶场的设计者也是够奇葩的，故意留这种漏洞，是不是在考验我们的耐心？还是想看看我们能想出多少种姿势来利用它，挖野菜。？

进入页面是一个钱包充值页面。界面简陋得让人想哭，就一个输入框和一个按钮。但是越是简单的东西，往往越藏着大杀器。这就是所谓的“大巧不工”吧？或者是“穷酸”？不管了反正能用就行。

具体表现与危害：在金额输入框中输入常规数值，点击 “确认充值” 按钮。充值后金额增加。这看起来很正常对不对？你要是输入100，它就给你充100，你要是输入50，它就给你充50。这有什么好玩的？别急，好戏在后头呢。如果你只看到这一层，那你还是太年轻了，实锤。。

我们要做的，就是打破这个常规。我们要输入一些它想不到的数字。比如超长的小数。或者，一些特殊的数值。这时候，就需要用到我们的神器——F12了，深得我心。！

手把手教你抓包：别告诉我你连F12都不会用

按下F12键打开浏览器开发者工具， 切换至 “网络” 面板，确保 “保留日志” 选项已勾选，以便捕获充值相关的请求和响应。 弄一下... 这一步是基本功，要是这都不会，建议先去补补课，别在这儿丢人现眼了。真的，我这是为了你好。

什么鬼？ 在数据包里有提示：输入0.018，成功获取flag。看到这个提示的时候，我差点笑出声来。这也太明显了吧？就像是把密码写在脑门上一样。不过这也说明了有时候最简单的办法就是最有效的办法。你不需要去构造什么复杂的Payload，也不需要去绕过什么WAF，你只需要听它的话，输入0.018。

我当场石化。 但是为什么是0.018呢？这背后肯定有猫腻。我猜，这肯定跟它的舍入逻辑有关。也许它只保留两位小数，然后0.018就被舍入成了0.02？或者是0.01？如果是0.02，那你充0.018，它给你算0.02，你是不是就赚了0.002？别嫌少，积少成多啊！如果你循环个一万次那就是20块！够吃顿好的了！

当然这只是我的猜测。具体的情况，还得看它的代码是怎么写的。不过既然提示都这么说了那我们照做就是了。输入0.018， 没眼看。 点击充值。然后奇迹发生了！真的成功了！flag到手！那一刻， 我感觉自己简直就是世界之王，用语言来形容的。

编程语言浮点数处理大比拼

没法说。 说到这里不得不提一下编程语言的问题。不同的语言，处理浮点数的方式也不一样。这也是导致舍入漏洞的一个重要原因。看看下面这个表格，你就知道为什么程序员总是掉坑里了。

看到JavaScript那个坑爹指数了吗？9.5！简直是地狱级难度。如果你用JS写支付逻辑，那你真的是在走钢丝。稍有不慎，就会掉下去摔个粉身碎骨。所以千万别在前端做金额计算，千万别！这是血的教训啊，醉了...！

修复建议：别让你的钱白白流失

出道即巅峰。 说了这么多漏洞， 怎么利用，怎么吐槽，再说说还是得说说怎么修。毕竟我们是有良知的白帽子。修复需围绕 “后端主导校验、拒绝信任前端数据” 核心原则，从数据校验、逻辑设计、监控审计三方面入手。这可是金科玉律，背下来！

先说说后端主导校验。前端传过来的数据，一个标点符号都不能信。前端说充100，后端得去查数据库，查订单，查用户状态，确认无误了才允许充值。 未来可期。 前端传过来的金额，后端得重新算一遍，用最严谨的方式算，比如BigDecimal。别嫌麻烦，麻烦总比丢钱强。

接下来逻辑设计要统一。别一会儿四舍五入，一会儿去尾，一会儿又银行家舍入。全系统必须统一一套标准。而且，最好用整数来存储金额，比如以“分”为单位。这样就没有小数点了也就没有舍入的问题了。这招虽然笨，但是最有效。很多大厂都是这么干的，你有什么理由不这么干，嗐...？

地道。 再说说监控审计。这就像装个监控摄像头。虽然不能防止小偷进来但是小偷进来了你能抓到他，还能把钱追回来。要对每一笔交易进行记录，对异常的金额变动进行报警。如果发现某个用户一直在充值0.018这种奇怪的数字，那肯定有问题，赶紧封号处理！

逻辑漏洞危害等级评估表

为了让大家更重视这个问题，我再放一个表格。这个表格是关于各种逻辑漏洞的危害等级的。看看舍入漏洞排在第几名？

蚌埠住了... 看到了吧？支付逻辑漏洞的危害等级是“S”级！仅次于越权访问。而且它的利用难度是“简单”！这意味着什么？意味着只要是个稍微懂点技术的人，都能利用这个漏洞搞事情。这能不让人害怕吗？这能不让人睡不着觉吗？

别把简单的问题复杂化

写到这里我都不知道自己在写什么了。感觉就像是在发牢骚。但是这确实是我的真实感受。好靶场支付逻辑中，充值舍入漏洞是否存在？答案是肯定的，不仅存在而且很常见。不仅仅是好靶场，在很多真实的系统中，这种漏洞都像幽灵一样徘徊，翻车了。。

我们不需要什么高深的黑客技术，也不需要什么复杂的攻击工具。我们只需要一个F12，一个聪明的脑袋， 你我共勉。 还有一点点运气，就能发现这些漏洞。这既是对开发者的考验，也是对平安人员的挑战。

我的看法是... 输入0.018，成功获取flag。这不仅仅是一个flag，这是对系统平安性的一个嘲讽。它在告诉我们，你的系统并不平安，你的逻辑并不严密。你需要做的还有很多，你需要学习的还有很多。

希望这篇文章能给大家带来一点点启发， 哪怕只是让大家知道了F12怎么用，或者知道了BigDecimal是个好东西，那我这篇文章就没白写。虽然写得很烂， 栓Q！ 很乱，充满了噪音，但是这就是生活啊，充满了混乱和噪音。我们要做的，就是在这些噪音中，找到那个关键的信号，那个能让我们成功的信号。

再说说 强调，修复需围绕 “后端主导校验、拒绝信任前端数据” 核心原则。记住这句话，保你平安。好了不说了我要去吃饭了饿了。这写文章真累人，比挖漏洞还累。大家再见，或者再也不见。反正我也不是什么大V，你们也不一定记得我。就这样吧，散了散了。