💻 computer science

Refunded but Rewarded: The Double Dip Attack on Cashback Reward Engines

本文通过实证研究揭示了现金返还奖励系统中因退款处理逻辑缺陷而导致的“双重获利”攻击漏洞，提出了形式化验证模型与防御方案，并披露了多家发卡机构的实际安全状况。

原作者： S M Zia Ur Rashid, Suman Rath

发布于 2026-04-21

📖 1 分钟阅读☕ 轻松阅读

原作者： S M Zia Ur Rashid, Suman Rath

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

这篇论文讲述了一个关于**“双重获利”（Double Dip）的有趣但危险的故事。简单来说，它揭示了信用卡和支付平台上的“返现奖励系统”存在一个巨大的逻辑漏洞，让用户可以“白嫖”**商家的返现，甚至还能把商品退回去拿回全款。

想象一下，你走进一家商店，买了一个东西，商店不仅给了你商品，还额外送你一张**“现金券”。然后，你转身把东西退给商店，商店把商品钱退给了你，但那张“现金券”**却还在你口袋里。

这就是论文中描述的**“双重获利攻击”**。

下面我用几个生动的比喻来拆解这篇论文的核心内容：

1. 核心问题：奖励系统的“健忘症”

现在的信用卡和数字钱包为了抢客户，都推出了返现活动（比如“买咖啡返 5%"）。

正常的逻辑应该是： 你买东西 -> 获得返现 -> 如果你退货 -> 商家把货款退给你，同时银行把刚才给你的返现也“收回去”。
论文发现的漏洞： 很多银行的奖励系统太“健忘”了。它们只记得你“买了东西”，却忘了你“退了货”。

比喻：
想象银行是一个**“自动售货机”**。

你投币买饮料（消费），机器吐出一瓶饮料，还额外吐出一枚金币（返现）。
如果你把饮料退回去（退货），机器应该把饮料收回，并且把刚才那枚金币也吞回去。
但有些机器（漏洞系统）只把饮料收走了，金币却留在了你手里。
结果：你手里有饮料钱（退款），手里还有金币（返现），而实际上你什么都没花。

2. 三种不同的“健忘”程度（漏洞分类）

论文调查了 6 家不同的银行/发卡机构，发现它们处理“退货”的方式分成了三个等级：

第一级：完全健忘（最危险）

代表： 某借记卡机构（Issuer A）。
现象： 只要钱退回来了，系统就完全不管之前的返现了。
比喻： 就像那个售货机，你退货时，它甚至懒得看一眼你手里的金币，直接让你走人。
后果： 用户可以无限循环：买 -> 拿返现 -> 退钱 -> 再买。只要每月有返现上限，就能每个月白拿一笔钱。

第二级：时间差攻击（有点小聪明）

代表： 某信用卡机构（Issuer B）。
现象： 系统不是完全健忘，但它算账的时间点有问题。它每个月底算一次账，把返现发给你。如果你在下个月退货，系统以为“上个月的事已经算完了”，就不再追回返现。
比喻： 就像公司发工资。你在 1 月 31 日发工资（拿到返现），2 月 1 日你辞职并退回了 1 月的工作成果（退货）。HR 说："1 月的工资已经发出去了，2 月的事我们不管。”于是你白拿了 1 月的工资。
后果： 利用“结账周期”和“退货窗口”之间的时间差，把返现“落袋为安”。

第三级：部分健忘（有补救但慢半拍）

代表： 某信用卡机构（Issuer F）。
现象： 系统知道要追回返现，但动作太慢。你退货后，系统要等到月底才来“算账”扣钱。
比喻： 就像你借了朋友钱，朋友说“我会追债”，但他要等到年底才来要。在这期间，你可以拿着这笔钱去花掉，甚至把卡注销（虽然论文说有些银行不允许在欠款时销户，但这给了用户一个“免费使用期”）。
后果： 虽然最终会追回，但用户利用了这段时间差，免费占用了资金。

3. 最完美的防御：像“记账本”一样严谨

论文还研究了另外三家做得很好的银行（Issuer C, D, E）。

做法： 它们把每一笔返现都死死绑定在具体的那笔交易上。
比喻： 就像一本**“带锁的账本”**。
- 你买咖啡，账本记：+1 元返现。
- 你退咖啡，账本立刻记：-1 元返现。
- 如果返现已经花掉了，你的账户余额就会变成负数（比如 -1 元）。
- 在你下次消费赚回这 1 元之前，你无法再提现或享受新的返现。
结果： 这种机制下，想“白嫖”是不可能的，因为系统会实时扣回，让你无利可图。

4. 为什么这很重要？

不仅仅是骗钱： 这不是那种偷卡号、伪造身份的“黑客攻击”。这是利用规则本身的漏洞。一个普通的消费者，只要稍微动点脑筋，就能合法地（用真卡、真交易）从系统里“抠”出钱来。
商业逻辑的疏忽： 银行在开发支付系统时，花了大力气防止黑客攻击，但在设计“奖励逻辑”时，却把它交给了市场部的人，导致逻辑上出现了这种“死循环”。
经济影响： 如果这种漏洞被大规模利用，银行每年可能会损失数亿美元。

5. 论文的建议（如何修补）

作者提出了一套简单的“补丁”方案，就像给那个售货机加一个**“智能传感器”**：

绑定交易： 每一笔返现都要记录它是哪笔交易产生的。
自动扣回： 一旦检测到退货，立刻按比例扣回返现。
允许负数： 允许用户的奖励账户变成负数，并强制要求用未来的消费来填补这个坑，不能直接销户逃避。
等待期： 在账单结算前，先别急着把返现发给用户，等退货窗口过了再发。

总结

这篇论文就像是一个**“系统体检报告”。它告诉我们：
现在的支付系统很安全，不容易被黑客攻破，但“奖励系统”却像个没锁好的抽屉**。只要有人懂得“先拿钱，再退货”的套路，就能把银行的钱装进自己口袋。

作者呼吁，银行应该像对待“支付安全”一样，严肃对待“奖励逻辑”的安全性，把“退货扣回”这个动作做得像“支付”一样严谨，堵住这个让普通人也能“白嫖”的漏洞。

论文技术总结：《Refunded but Rewarded: The Double Dip Attack on Cashback Reward Engines》

1. 研究背景与问题定义

随着信用卡、借记卡和数字钱包的普及，返现（Cashback）和忠诚度奖励计划已成为支付平台竞争的核心工具。然而，尽管底层的支付授权和结算系统经过了数十年的安全审查，奖励引擎（Reward Engines）的业务逻辑却往往被忽视。

本文揭示了一类被称为**“双重获利攻击”（Double Dip Reward Abuse Attack, DDRA）**的新型业务逻辑漏洞。攻击者利用奖励系统在交易退款（Refund）处理上的逻辑缺陷，实现以下恶意循环：

购买：用户进行合法购买并获得返现奖励。
兑换：用户立即将奖励兑换为现金或账单抵扣。
退款：用户随后将商品退回并获得全额退款。
获利：由于奖励引擎未能正确扣减已兑换的奖励，用户实现了零净支出但保留正净奖励的确定性获利。

这种攻击不涉及身份盗窃、伪造卡片或虚假索赔，而是利用合法账户和标准交易流程中的逻辑漏洞。

2. 方法论与实验设计

作者通过受控的小规模实证实验，在六家美国主要金融机构（发卡行）的合法个人账户上进行了测试。

实验对象：6 个发卡行账户（涵盖借记卡和信用卡产品）。
攻击模型：假设攻击者为“诚实但投机”的消费者（Honest but Opportunistic），仅使用公开文档的功能（购买、退款、兑换），通过策略性地选择操作时机来利用系统缺陷。
实验流程：
1. 在奖励类别中进行小额购买。
2. 等待奖励到账并立即兑换。
3. 通过标准商户流程发起全额或部分退款。
4. 观察奖励账本（Reward Ledger）是否进行了相应的扣减（Clawback）。
建模方法：将奖励引擎抽象为状态机（State Machine），定义交易状态（待处理、已结算、部分退款、已退款等）及奖励账本的转换规则。

3. 核心发现：漏洞分类与案例研究

研究将奖励系统的退款处理逻辑划分为三个层级，揭示了三种主要的漏洞类别（V1, V2, V3）：

3.1 第一类：退款不敏感（V1 - Case I: Issuer A）

现象：借记卡返现程序在交易退款后完全忽略奖励调整。
攻击路径：购买 -> 获得奖励 -> 兑换现金 -> 退款 -> 奖励未被扣回。
结果：用户实现零成本获利，且该循环可每月重复（受限于月度上限）。
漏洞本质：奖励引擎缺乏退款事件处理器，违反了“购买->奖励->退款->奖励调整”的工作流。

3.2 第二类：时间窗口漏洞（V2 - Case II: Issuer B）

现象：基于账单周期（Statement Cycle）的奖励计算结合自动兑换功能。
攻击路径：
1. 在周期 $n$ 购买，周期结束时自动计算奖励并兑换。
2. 在周期 $n+1$ （仍在商户 30 天退货期内）发起退款。
3. 由于退款发生在奖励计算周期之后，系统无法追溯扣减上一周期的已结算奖励。
结果：利用账单周期与商户退货窗口之间的时间差，实现跨周期的奖励套利。

3.3 第三类：负余额处理不一致（V3 - Case III）

稳健型（Issuer C, D, E）：
- 实施无限期负余额强制（Indefinite Negative Balance Enforcement）。
- 退款后，若用户已兑换奖励，账本会变为负数。
- 后续产生的奖励必须先填补负余额，用户才能再次兑换。
- 结果：完全防御 DDRA 攻击。
半稳健型（Issuer F）：
- 时间不对称（Timing Asymmetry）：奖励在交易结算后立即可用（可立即兑换），但退款扣减（Clawback）仅在账单周期结束时批量处理。
- 攻击路径：用户利用结算与账单截止之间的时间差，先兑换奖励再退款。虽然最终会产生负余额，但用户已提取了价值，且若停止使用该卡，负余额可能长期无法追回。

4. 形式化模型与防御算法

作者提出了形式化的**奖励完整性（Reward Integrity）和退款奖励一致性（Refund Reward Consistency）**不变量，并设计了四个防御算法：

Algorithm 1 (RewardOnSettlement)：交易结算时计算奖励，记录原始奖励值（不可变）和当前奖励值。
Algorithm 2 (RewardOnRefund)：处理退款事件，基于原始奖励值进行比例扣减（Proportional Clawback），允许账本变为负数。
Algorithm 3 (CanRedeem)：兑换前的守卫检查。
- 检查是否处于“宽限期”（Grace Period，防止账单刚结束时的退款未处理）。
- 检查兑换后余额是否低于最小阈值（通常为 0），防止透支。
Algorithm 4 (StatementCycleReconcile)：针对账单周期系统的批量对账。
- 处理当期未决退款。
- 追溯扣减：处理跨周期的迟来退款（Late Refunds），调用 Algorithm 2 进行修正。

正确性论证：在假设退款事件最终会被送达且处理原子性的前提下，该算法组能确保用户的净奖励永远不超过其净支出的理论奖励上限。

5. 关键贡献

实证案例研究：首次通过真实生产环境账户，系统性地揭示了返现奖励引擎中的业务逻辑漏洞，并构建了包含三种漏洞类型的分类法。
形式化建模：将奖励引擎建模为状态机，定义了“奖励完整性”和“退款一致性”两个关键安全属性，并将漏洞映射到 CWE-841（行为工作流执行不当）和 OWASP Business Logic Abuse Top 10 类别。
防御性算法设计：提出了一套半形式化的防御算法，包括比例扣减、负余额强制和跨周期对账机制，从设计层面（By Construction）消除漏洞。
负责任的披露：
- Issuer A：通过漏洞赏金计划报告，已被厂商确认为已知漏洞。
- Issuer B：在尝试多种联系渠道无果后，进行了匿名化披露。
- Issuer F：作为设计权衡案例进行描述，未进行正式漏洞披露。

6. 研究意义与影响

安全视角的转移：强调奖励引擎应被视为与支付授权逻辑同等重要的安全关键组件，需要明确的状态转换和不变量约束。
经济影响：虽然具体损失取决于用户基数和滥用比例，但模型显示，若大规模发生，每年可能导致数千万甚至数亿美元的奖励资金流失（基于敏感性分析）。
行业指导：
- 指出“检测”（Detection）不足以解决问题，必须依靠“预防”（Prevention）和“设计即安全”（Security by Design）。
- 建议发卡行实施逐笔交易奖励追踪、比例扣减机制以及负余额强制执行策略。
- 为监管机构（如 CFPB）关注奖励计划的公平性和透明度提供了技术依据。

7. 结论

本文证明了即使在没有技术入侵（如 SQL 注入）的情况下，仅凭对业务逻辑的投机性利用，也能从现代支付系统中提取确定性利润。通过引入状态机模型和防御性算法，作者展示了构建鲁棒奖励系统的可行性，并呼吁行业将奖励逻辑纳入严格的安全审查范围。