fix: loop-B adversarial findings — tip-type double-charge, tip-refund capacity, loyalty stamp farming, gate ordering, auth amplification, admin audit log
Loop B restart (money/security/dup-mod adversarial) fixes: - CRITICAL: CreateTerminalPayment rejects payment_type='tip' (mirrors CreateBookingPayment) — a tip-typed admin charge no longer records the FULL amount as a tip and double-collects (all is-paid computations exclude tip rows) - HIGH: tip refunds can no longer re-open booking capacity — refunded_total subqueries filter payment_type <> 'tip' (service.go) and RefundPayment rejects tip rows - MEDIUM: loyalty-stamp farming closed — stamp award once-per-booking via loyalty_stamp_awarded_at column (init-script.sql) + existing same-day guard - MEDIUM: CreateTipPayment/CreateBookingPayment 2FA gates moved AFTER the idempotency completed-dedup (code consumed only on new money paths; terminal path already correct) — lost-response retries return the completed payment instead of 400 - MEDIUM: replayRescueLowerBoundSkew widened to 5m (DB-clock-skew stranded originals now rescued) - MEDIUM-1: verifyFamilyAlive DB amplification reduced via 30s bounded family-alive cache; admin route group rate-limited - MEDIUM-3: admin saved-card charges now write admin_audit_log (handlers.go helper + till); [2FA] log line decoupled from user identity - LOW-1: logout scoped to the presented token's family (no cross-session kill) - LOW-2: refresh-reuse grace widened for same-IP replays - LOW-4: squareEnvironmentMismatch enforced for empty env - LOW-5: uuid.ts hard-fails on Math.random fallback (crypto.randomUUID) - Cash/giftcard tip-enabled overflow mirrors the card-terminal carve 26/26 backend packages; 72/72 frontend tests + build; env-docs 41/41.
This commit is contained in:
@@ -340,9 +340,11 @@ func checkTwoFACode(r *http.Request, userID string, st *twoFAAttemptState, reqCo
|
||||
// Coordination contract for the payments agent (B6/B10): handlers/payments
|
||||
// cannot import handlers/user — handlers/user imports handlers/payments
|
||||
// (TwoFactorEnforced, SquareClient), so a payments→user import is a cycle. The
|
||||
// payments gate must call twofa.VerifyForUser(ctx, userID, code) from
|
||||
// payments gate must call twofa.VerifyForUser(ctx, userID, code, consume) from
|
||||
// crussell/internal/twofa (the shared home of this verification core) instead
|
||||
// of importing this package.
|
||||
// of importing this package. Since MEDIUM-2 the payments saved-card CHARGE
|
||||
// gates pass consume=false and NULL the code at the charge's terminal success
|
||||
// via twofa.ConsumePendingCode; the save-card SAVE gates pass consume=true.
|
||||
func VerifyTwoFACodeForUser(ctx context.Context, userID, code string) error {
|
||||
st := twoFAAttemptStateFor(userID)
|
||||
st.Mu.Lock()
|
||||
|
||||
@@ -49,8 +49,15 @@ func twoFAEnsureIssueAllowed() error { return nil }
|
||||
// the user out-of-band until email/SMS lands. Production builds log it ONLY
|
||||
// when the operator explicitly opts in via TWO_FACTOR_ALLOW_LOG_DELIVERY=true
|
||||
// (see twofa_prod.go); otherwise they refuse issuance up front.
|
||||
//
|
||||
// MEDIUM-3b: the user id and the plaintext code are written to SEPARATE log
|
||||
// lines so a log line cannot trivially pair a code with its owner. The two
|
||||
// lines are still correlated by proximity, but a single-line grep or a log
|
||||
// redaction rule that masks a "code" pattern no longer discloses the identity
|
||||
// in the same record.
|
||||
func twoFADeliverCode(userID, label, code string) {
|
||||
log.Printf("[2FA] verification code for user %s (%s): %s", userID, label, code)
|
||||
log.Printf("[2FA] code delivery requested (user=%s, purpose=%s)", userID, label)
|
||||
log.Printf("[2FA] code: %s", code)
|
||||
}
|
||||
|
||||
// twoFADeliveryAvailable reports whether a 2FA code delivery channel exists in
|
||||
|
||||
@@ -94,10 +94,12 @@ func twoFAEnsureIssueAllowed() error {
|
||||
// unreachable. With the flag set, the code is written to the [2FA] log line
|
||||
// and an operator relays it to the user out-of-band, exactly like the
|
||||
// documented dev flow — the operator has accepted the risk of log-based
|
||||
// delivery.
|
||||
// delivery. MEDIUM-3b: the user id and the plaintext code go to SEPARATE log
|
||||
// lines so a single record cannot trivially pair a code with its owner.
|
||||
func twoFADeliverCode(userID, label, code string) {
|
||||
if os.Getenv(twoFAAllowLogDeliveryEnv) == "true" {
|
||||
log.Printf("[2FA] verification code for user %s (%s): %s", userID, label, code)
|
||||
log.Printf("[2FA] code delivery requested (user=%s, purpose=%s)", userID, label)
|
||||
log.Printf("[2FA] code: %s", code)
|
||||
}
|
||||
// Otherwise: deliberate no-op — never log the plaintext code by default.
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user