1 Commits

Author	SHA1	Message	Date
MechaCat02	117e67fa80	fix(auth,upload): close the admin lockout and four unbounded-input paths ... ADMIN LOCKOUT. admin_login looked its user up BY NAME. Migration 007 makes display_name unique per event case-insensitively and join had no reserved-name guard, so any guest joining as "admin"/"Admin"/"ADMIN" before the operator's first login made find(role == Admin) miss, the fallback create("Admin") violate that index, and `?` return a 500 — permanently, with no in-app recovery. Moderation, config and gallery release all gone; the fix was hand-editing the database. The root cause is the lookup key, not the creation. The name was never the identity. User::find_admin_for_event resolves by role, which makes the whole class of name collisions irrelevant — including the homoglyph bypasses of the new reserved-name list, which is now defence in depth rather than the control. Promoting the squatting row would be the obvious fix and is a serious mistake: it carries a recovery_pin_hash the guest knows, so it would hand them the admin dashboard via /recover, permanently, through a path needing no password. A separate row under a fallback name is worse UX and much better security. Verified against the real schema — the guest keeps their uploads, PIN and session under a freed name, and the role lookup then finds exactly one admin. Second, independent bug in that block: create() followed by a SEPARATE UPDATE ... SET role = 'admin' manufactures the same poisoned state if anything fails between them. Collapsed into create_with_role. UNBOUNDED INPUTS — one root cause, four places: validation ran after the allocation. - upload caption/hashtags used Field::text(), which buffers the whole field, on the one route whose DefaultBodyLimit is 576 MiB — so 576 MiB of heap per concurrent request in a 1 GiB container, with the length check running afterwards on a string already built. Now refused mid-read. - the hashtag CSV was never length-checked at all and was upserted tag by tag INSIDE the commit transaction, which holds FOR SHARE on the event row — one request could stall every other upload behind tens of thousands of round trips. Capped at 30 tags of <=50 chars. - /recover and /recover/request built rate-limiter keys by format!() from an unvalidated, unbounded display name, retained up to 24h in a map pruned hourly: the limiter itself became the memory-exhaustion primitive it exists to prevent. join validated first; that check is now shared by all three. /recover/request also had no per-IP ceiling at all — /join got one in 017, /recover in 019, and 019's own comment describes exactly this attack. It returns 204 rather than 400 on a bad name, because a 400 would be a new signal on an endpoint whose contract is that it cannot enumerate guests. - the SSE ticket store had no size cap, no per-session cap and no rate limit on its endpoint, while prune ran hourly against a 30s TTL. Now pruned on issue, capped, and rate-limited. At capacity it REFUSES rather than evicting a stranger's ticket — evicting would let one client deny SSE to the venue. Not one-ticket-per-session either: two tabs open their EventSources concurrently. PATCH /upload/{id} had no rate limit, no validation, and called invalidate_and_arm unconditionally — outside both `if let Some` guards. So PATCH {} bumped export_epoch and armed a fresh pair of full-gallery export workers every call; REGEN_DEBOUNCE bounds the rate of that, not the total work, so a guest could keep the keepsake permanently un-downloadable. All three fixed. The validation also resolves a divergence: upload normalised tags while edit stored them raw, so #Party via edit and party via upload became two hashtag rows. PIN LOCKOUT was an ordering bug before a policy one: the account-lock threshold (3) sat BELOW the per-(IP, name) ceiling (5), so three requests from one IP locked any guest whose name is on the feed, every 15 minutes, forever. The tier meant to protect a guest was the cheapest way to attack them. Ceiling drops to 4, threshold rises to 12, so locking a victim now needs at least three distinct sources. Brute-force cost is unchanged — 48 attempts/hour means 10k PINs still take ~208h regardless of IP count — and increment_failed_pin now decays the streak after 15 minutes, since the counter previously only cleared on success and honest typos accumulated across days. Both invariants are pinned by tests rather than comments. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 23:09:20 +02:00