Loyalty Loophole

Your account has store credit, and you can spend £5.00 of it on a voucher. The shop checks you have enough, then deducts it. Between those two steps there is a tiny gap, and if you ask for a voucher several times at once, every request checks your balance before any of them deducts. They all see the same £5.00, they all say yes, and you walk away with a fistful of vouchers for a single fiver. This is a race condition.

1 · Find it

On alice’s account page there is £5.00 of store credit and a Claim a £5 voucher button. That button is meant to work exactly once: £5.00 buys one voucher and the credit drops to £0.00. Check the credit really does say £5.00 before you start. (If it says £0.00, this account has already spent it: see running it again below, or log in as bob, who also starts with £5.00.)

The flaw is the gap inside that one button. Behind it, the server first checks you have £5, then a moment later deducts it and issues the voucher. Land several requests in that gap at once and they all pass the check before any of them deducts.

2 · Exploit it

The command needs alice’s session cookie so the shop treats the requests as her. Open developer tools (right-click → Inspect, or F12 / Cmd+Option+I), go to the Application tab (Chrome/Edge) or Storage tab (Firefox) → Cookies → http://localhost:3000, and copy the value of the ff_session row.

With alice still at £5.00, swap YOUR_COOKIE for that value and run the command below. It fires 10 claims at the same instant and prints the voucher code each one hands back:

seq 10 | xargs -P10 -I{} curl -s -b "ff_session=YOUR_COOKIE" \
  -X POST http://localhost:3000/rewards/claim | grep -oE "Voucher [0-9A-F]+"

1..10 | ForEach-Object -Parallel { curl.exe -s -b "ff_session=YOUR_COOKIE" -X POST http://localhost:3000/rewards/claim } -ThrottleLimit 10 | Select-String -Pattern "Voucher [0-9A-F]+"

The terminal prints around ten different voucher codes, one for each claim that succeeded. Now reload alice’s account page: the credit has gone negative, roughly £-45.00. A single £5.00 balance just bought ten vouchers, because all ten claims checked the balance before any of them deducted. (There is no list of vouchers on the page, so the codes in your terminal and the negative credit are the proof.)

3 · Understand it

The handler reads the balance, waits on something, then deducts. That wait is all the gap a parallel request needs:

const me = getCredit(userId);
if (me.credit < 500) return tooPoor();
await checkLoyaltyService();          // <- others slip in here
setCredit(userId, me.credit - 500);   // everyone deducts from the same start
issueVoucher(userId);

4 · Fix it

Make the check and the deduction one atomic operation, so only one request can win. A single conditional UPDATE does it: deduct only if enough is there, and let the database serialise the writes:

if (getCredit(id) >= 500) {
  await something();
  setCredit(id, credit - 500);
}

const r = db.prepare(
  `UPDATE customers SET credit_pence = credit_pence - 500
   WHERE id = ? AND credit_pence >= 500`
).run(id);
if (r.changes === 1) issueVoucher(id);

Now two claims cannot both succeed: the first row update wins, the second finds the credit already gone and changes nothing.