I test what happens between the check and the write.

Claim

The /transfer endpoint reads the sender's balance, checks that funds are sufficient, then writes the new balance as a separate operation with no atomic database transaction and no row locking. Ten concurrently sent transfer requests all pass the balance check using the same stale value before any write completes (TOCTOU).

Parallel requests

(Screenshot 4) EXPLOITATION: ten transfers of 900 are sent concurrently -> all are reported successful.

POST /transfer HTTP/1.1
User-Agent: python-requests/2.33.1
Accept-Encoding: gzip, deflate, br, zstd
Accept: */*
Connection: keep-alive
Authorization: Bearer [REDACTED-LAB-TOKEN]
Content-Length: 43
Content-Type: application/json

{"to_account": "9159912486", "amount": 900}

Result

-8100.0

(Screenshot 5) CIA IMPACT: the attacker's balance becomes -8100.0, negative and beyond the funds ever held.

Why it worked

Ten concurrently sent transfer requests all pass the balance check using the same stale value before any write completes (TOCTOU).

CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization · OWASP A04:2021 - Insecure Design

Fix

What the fix changes.

• Perform the balance check and the debit in a single atomic database transaction.
• Lock the sender's account row (SELECT ... FOR UPDATE) or use a conditional update UPDATE ... SET balance = balance - x WHERE balance >= x.
• Add a CHECK (balance >= 0) constraint on the balance column as a safety net.
• Apply an idempotency key and rate limiting to the transfer endpoint.