1 commit

Author	SHA1	Message	Date
ScreenTinker	d4b8d7dad4	SSO: prove domain ownership by DNS, and fix what the second review found ... A second review pass, run against the previous commit, found four blockers — two of them introduced by the fixes in that commit. It also confirmed the original account takeover is closed: a hostile IdP with real TLS, discovery, JWKS and RS256 driving the real routers now stops at domain_not_allowed, and all 16 bypass variants are refused. DOMAIN OWNERSHIP (the root cause, not the symptom) A claimed domain used to mean "nobody else claimed it". It now means the organization published a record in that domain's own DNS — TXT or CNAME, at a dedicated _screentinker-verify name rather than the apex, where an edit would sit beside SPF. - an unverified domain routes NOBODY and cannot be asserted; it reserves the name - an unverified claim LAPSES after 8 hours, so a domain cannot be held against its real owner, and lapsing rotates the token so a record left over from an abandoned attempt cannot satisfy a later claim - a verified domain never expires — re-proving on a timer would log a customer out over a DNS edit made months later - routing and confinement read the VERIFIED set only, never the typed column - configuring SSO now requires a verified email address - platform admins are emailed when a domain is claimed; nothing is ever sent to the claimed domain, which would let any tenant make this product email third parties Instance-wide providers are exempt from all of it: they are the operator's own configuration and keep the trust they have always had. BLOCKERS FROM THE REVIEW - two unauthenticated remote crashes, both one request, both "async handler throws before its try": `Cookie: st_oidc_tx=%` (unguarded decodeURIComponent) and the fail-closed secret added last commit, which turned a JWT_SECRET rotation into a permanent crash loop. Fixed the CLASS with asyncRoute() rather than the instances. - the SSRF guard was bypassable via IPv4-mapped IPv6 ([::ffff:127.0.0.1]) and also refused every host beginning "fc"/"fd" (fcm.googleapis.com). Addresses are now parsed and compared by RANGE. 42 cases verified. - the takeover fix had NO test — the test named after it asserted two struct fields and passed with the guard deleted. The decision is now a pure function and four mutations were confirmed to turn the suite red. - the PUT path never received the TOCTOU fix, so two orgs could end up holding one domain and forEmail handed routing to the attacker's older row. ALSO - linking compared slugs, so an org could never rotate its own IdP, and fell open on an empty auth_provider. It now asks which ORGANIZATION owns the slug. - an account stranded by a deleted provider can be reclaimed by password reset — proof of the mailbox, which is stronger than the IdP assertion that created it. - /sso/claim accepted a pre-TOTP mfa_pending token and returned the full user row; it now takes a purpose-built 120s claim token with a pinned algorithm and typ. - the rate limiter keyed on a caller-controlled path, so a trailing slash bought a fresh bucket — a real login brute-force bypass. - domain_not_allowed and account_exists_other_provider rendered as "please try again", advice that can never work. - malformed asserted addresses are refused rather than trimmed into shape. - dead config (microsoftTenantId defaulted to 'common', which the provider code now refuses) and the orphaned google-auth-library dependency removed. 1591 tests pass. Domain lifecycle verified end to end against a running server. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Bvjey4FNam49MN7ybjcq6A	2026-08-10 19:23:46 -05:00