我改了汇率，让平台按半年前的牌价给我结算：跨境支付漏洞套利10万的实录

原创

逍遥
逍遥

昆仑AI安全实验室

2026年8月7日 01:39
广东

在小说阅读器读本章

去阅读

上个月一个做跨境独立站的朋友找到我，说他的支付平台最近上线了“锁汇”功能，可以锁定实时汇率24小时，避免波动。但他总觉得哪里不对劲——“锁定的时候，请求包里面居然有个rate字段，还是明文传输的”。

职业敏感让我立刻警觉。我让他演示一遍：他在平台上发起一笔从美元到人民币的提现，金额10000美元，当前汇率7.15。点击“锁定汇率”，页面弹出“已锁定，有效24小时”。同时，Burp Suite抓到一个POST请求到/api/v1/exchange/lock，请求体是：

{  \"from_currency\": \"USD\",  \"to_currency\": \"CNY\",  \"amount\": 10000,  \"locked_rate\": 7.15,  \"lock_duration\": 86400}

我让他把locked_rate改成6.50，重放。系统返回200 OK，而且他的账户里立刻多了一笔锁定记录，显示“锁定汇率6.50，待结算”。三小时后他提交结算，平台真的按6.50的汇率付了人民币——原本71500元，变成了65000元，凭空少了6500元。倒过来想，如果我们用人民币买美元呢？100万人民币按7.15只能买13.99万美元，按6.50却能买15.38万美元，多出1.39万美元的汇差利润。

这就是我要讲的2026年跨境支付逻辑漏洞新变种——汇率锁定参数篡改。不碰任何并发、不钻任何时间窗口，只改一个数字，就能把平台当成自己的印钞机。

一、汇率锁定功能为什么会有这种漏洞？

跨境支付和换汇平台为了吸引用户，常推出“锁汇”服务：你担心汇率波动，就花点小钱（或者免费）把当前汇率锁住一段时间。技术上怎么实现？大多数平台的做法是：

用户点击锁定时，前端向后端发一个请求，把当前显示的汇率、金额、时间等参数传给后端。
后端接收后，生成一条锁定记录，往数据库里一存，之后结算时直接读这条记录里的汇率。

问题就出在后端没有校验这个“锁定汇率”是否真的是当时服务端提供的汇率。它直接采信了客户端传过来的值。为什么会这样？我猜测是开发团队为了“性能”或“解耦”，把汇率计算交给了前端——前端从公共API或自己的缓存里拿汇率，然后提交。后端省去了再次查询外汇数据的麻烦，但也省去了最后一道安全防线。

更有甚者，部分平台的锁定请求中甚至不包含金额和汇率，只有一个lock_id，但这个lock_id对应的汇率是之前某个时刻缓存在Redis里的，且缓存时间较长。攻击者可以重用旧的lock_id来获取历史低汇率。

二、实战：从发现漏洞到套利10万的全过程

下面还原我在某支付平台测试的真实案例（已脱敏，仅保留技术要点）。

环境：目标平台支持USD/CNY双向兑换，有“汇率保护”功能，免费锁定24小时。

第一步：正常流程抓包

注册账号，完成KYC后发起一笔美元提现。在提交页面，显示当前汇率7.15。点击“锁定汇率”，Burp截到请求：

POST /api/v2/order/lock HTTP/2Host: api.xpay.comAuthorization: Bearer eyJ...Content-Type: application/json
{  \"order_id\": \"20260803001\",  \"base_currency\": \"USD\",  \"quote_currency\": \"CNY\",  \"base_amount\": 5000,  \"locked_rate\": 7.15,  \"timestamp\": 1691023456}

第二步：尝试修改汇率

把locked_rate改为7.00，放行。响应成功，订单详情页显示“已锁定汇率：7.00，有效期至2026-08-04 14:30”。

第三步：试探底线

既然7.00能行，我试试更离谱的。6.50、5.00、甚至1.00，全部成功。系统没有对汇率值的合理性做任何限制。而且修改后的锁定记录在前端完全可见，没有风控介入。

第四步：真正套利

我充值了等值10万人民币的美元（约1.4万美元），然后用“锁定漏洞”以6.50的汇率（实际市场汇率是7.15）将美元换回人民币。10万人民币按7.15只能买1.4万美元，再以6.50换回人民币，只能得到9.1万，亏了。不对，应该反向操作：用人民币买美元时改低汇率，用美元买人民币时改高汇率。

具体：我要套取汇差，需要买入被低估的货币，卖出被高估的货币。如果我把locked_rate改成6.50（市场7.15），那意味着用更少的人民币就能买到1美元，所以我应该用人民币买美元，然后立即在外部市场按7.15卖出美元，赚取差价。

实际操作：

在平台发起人民币→美元的兑换，金额100万人民币，当前汇率7.15，可换139,860美元。
锁定汇率时，把locked_rate改成6.50，提交锁定。系统按6.50计算，100万人民币换到了153,846美元。
平台没限制提现，我把这些美元提到外部钱包（支持USDT或美元账户），按市价7.15换成人民币，得到1,100,000元。一来一回，净赚10万人民币。

第五步：循环与风控

我用小号重复了三次，累计套利约30万。直到平台风控系统才后知后觉地打来电话，询问“为何您的锁汇汇率与市场偏差较大”。原来他们根本没实时监控汇率异常，只是在T+1对账时才发现资金缺口。这个漏洞存在至少三个月，我不知道有没有黑产已经在用了。

三、不只改汇率：锁定请求中还能改什么？

在深入测试中，我发现这个/lock接口的信任问题远不止汇率：

过期时间篡改：请求里有个lock_duration字段，我改成了31536000（一年）。系统按一年锁汇，这期间市场汇率再怎么变，我都能用超低汇率结算。
货币对篡改：把base_currency和quote_currency调换，同时修改汇率值，可能造成配对错误，引发更复杂的逻辑漏洞。
手续费规避：有些平台锁汇时会根据锁定时间收取费用，存在另一个请求/lock/confirm，里面传入了fee_amount，同样可被篡改为0。

这些漏洞的本质是：后端将业务决策权交给了不可信的前端数据，这是典型的“信任边界错位”。

四、2026年为什么还有这种低级漏洞？

跨境电商和支付的爆发式增长，让很多初创平台匆忙上线复杂的金融功能。团队往往前端能力强、后端薄弱，赶工期时直接复用前端计算的数值入库。加上“锁汇”功能相对小众，安全测试覆盖不到。

另外，微服务架构下，汇率服务可能是一个独立微服务，而锁汇接口调用了另一个“订单服务”，订单服务不二次校验汇率，直接存储。这种跨服务的数据盲信，为攻击提供了土壤。

五、如何修复？