Chapter 35 — Web race conditions

Practice (75 min)

1. PortSwigger Academy "Race conditions" track: limit overrun, multi- endpoint, single-endpoint, partial construction, time-sensitive; use Turbo Intruder and Repeater's single-packet "send group in parallel".
2. Locally: the gift-card example with check -> act -> mark. Redeem it 10x with a parallel harness. Then fix four ways (conditional UPDATE + rows_ affected; UNIQUE redemption row; FOR UPDATE; idempotency key) and re-test each.
3. Build the "apply coupon while paying" multi-endpoint race; fix with a transaction that recomputes and locks the order total at capture (Ch 27 / G1 Ch 45).
4. Build the OTP-verify race (unlimited guesses by racing the attempt counter); fix with an atomic decrement WHERE attempts_left > 0.
5. Add a reusable "parallel N, assert exactly one success" test helper to your test suite and point it at every "once" operation.

Build it in Go (25 min) — a limit-overrun race, and the one-statement fix

A gift card worth one redemption, 20 requests released at the same instant. The vulnerable handler checks the balance, waits for the "database", then writes. The fixed handler does both in one conditional update.

// race: the "limit overrun" web race condition (Chapter 35). A gift card
// worth 100 is redeemed by 20 parallel requests. Check-then-act lets many of
// them win; a single conditional update lets exactly one win.
//
//	go run ./race
//	go run -race ./race     # note: the race detector reports NOTHING here
package main

import (
	"fmt"
	"net/http"
	"net/http/httptest"
	"sync"
	"time"
)

// db stands in for a database: every method is ONE atomic statement.
type db struct {
	mu      sync.Mutex
	balance map[string]int
}

func (d *db) get(card string) int { // SELECT balance FROM cards WHERE id = $1
	d.mu.Lock()
	defer d.mu.Unlock()
	return d.balance[card]
}

func (d *db) set(card string, v int) { // UPDATE cards SET balance = $2 WHERE id = $1
	d.mu.Lock()
	defer d.mu.Unlock()
	d.balance[card] = v
}

// debitIfEnough is the fix as ONE statement:
//
//	UPDATE cards SET balance = balance - $2 WHERE id = $1 AND balance >= $2
//
// The check and the write can't be separated, so no request can slip between them.
func (d *db) debitIfEnough(card string, amount int) bool {
	d.mu.Lock()
	defer d.mu.Unlock()
	if d.balance[card] < amount {
		return false
	}
	d.balance[card] -= amount
	return true
}

func vulnerable(d *db) http.HandlerFunc {
	return func(w http.ResponseWriter, r *http.Request) {
		bal := d.get("gift-1") // 1. check
		if bal < 100 {
			http.Error(w, "insufficient balance", http.StatusPaymentRequired)
			return
		}
		time.Sleep(5 * time.Millisecond) // the round trip to the database: the race window
		d.set("gift-1", bal-100)         // 2. act, on a value that may be stale
		w.Write([]byte("redeemed"))
	}
}

func fixed(d *db) http.HandlerFunc {
	return func(w http.ResponseWriter, r *http.Request) {
		if !d.debitIfEnough("gift-1", 100) {
			http.Error(w, "insufficient balance", http.StatusPaymentRequired)
			return
		}
		w.Write([]byte("redeemed"))
	}
}

func attack(name string, h func(*db) http.HandlerFunc) {
	d := &db{balance: map[string]int{"gift-1": 100}} // worth ONE redemption
	srv := httptest.NewServer(h(d))
	defer srv.Close()

	// 20 requests released at the same instant (the "single-packet attack"
	// does this over one HTTP/2 connection to remove network jitter).
	start := make(chan struct{})
	var wg sync.WaitGroup
	var mu sync.Mutex
	wins := 0
	for i := 0; i < 20; i++ {
		wg.Add(1)
		go func() {
			defer wg.Done()
			<-start
			resp, err := http.Post(srv.URL, "text/plain", nil)
			if err == nil {
				if resp.StatusCode == http.StatusOK {
					mu.Lock()
					wins++
					mu.Unlock()
				}
				resp.Body.Close()
			}
		}()
	}
	close(start)
	wg.Wait()
	fmt.Printf("%-12s 20 parallel redemptions of a 100-credit card: %2d succeeded, final balance %d\n",
		name, wins, d.get("gift-1"))
}

func main() {
	attack("vulnerable", vulnerable)
	attack("fixed", fixed)
}

$ go run ./race
vulnerable   20 parallel redemptions of a 100-credit card: 20 succeeded, final balance 0
fixed        20 parallel redemptions of a 100-credit card:  1 succeeded, final balance 0

$ go run -race ./race
vulnerable   20 parallel redemptions of a 100-credit card: 20 succeeded, final balance 0
fixed        20 parallel redemptions of a 100-credit card:  1 succeeded, final balance 0

What to notice:

• 20 wins on a card worth 1. Every request read the balance (100) before any of them wrote it, and then each wrote "100 − 100".
• Go's race detector reported nothing, correctly. There's no data race: every read and write is properly locked. This is a logic race across two atomic operations, which no memory-model tool can find. Only design (a single conditional statement, SELECT ... FOR UPDATE, or a unique constraint) or testing that fires requests in parallel finds it.
• The fix is the SQL in the comment: UPDATE cards SET balance = balance - $2 WHERE id = $1 AND balance >= $2, then check that exactly one row was affected.

Exercises:

1. Implement the fix with a database you use (Postgres or SQLite): first with SELECT ... FOR UPDATE in a transaction, then with the conditional UPDATE. Measure both under 200 parallel requests.
2. Apply the same pattern to "one coupon per user" with a unique index on (user_id, coupon_id), letting the database reject the duplicate.
3. Reproduce the attack over HTTP/2 against your staging service using Burp's single-packet attack, and confirm the fix holds.