- Spegnimento
- 19 agosto 2026 alle ore 08:09 UTC
- Autore
- Kamo
- Impegno
- 19ddc01
Due metà di un incidente. Un account registrato, verificato un indirizzo a un usa e getta provider, ha preso una sessione di auto-login e ha creato cinque organizzazioni in tre minuti e 40-due secondi — quattro di loro byte-identical "Acme Corp" righe che differiscono solo nella loro dominio. Ha prodotto righe ZERO in system access logs, quindi non c'è IP e nessun utente-agent per qualsiasi cosa. - Per forzare la bandiera... - Utente Servizio: `u.is fake = FALSE` va in ACCOUNT QUERY PREFIX, non in un chiamante. Tutti e tre gli identificatori di login — nome utente, e-mail di account, e la casella di posta primaria re-lookup keyed by id — riutilizzare quella proiezione, quindi una clausola chiude tutti e tre e una quarto identificatore aggiunto in seguito lo eredita. Un account contrassegnato legge come inesistente e ottiene il generico "utente non esiste o password è errato"; un messaggio che nomina bandiera direbbe a un abusatore esattamente cosa cambiare. - KSessionService.createSession: rifiuta il diritto. Questa è la vita più stretta nella sistema per "può questo atto conto" — ogni *** è coniato qui, così un cancello copre password login, enter-as, desktop SSO, dispositivo auth E l'imbuto del registro post-verificazione auto-login, che è come l'account in questione ha ottenuto una sessione senza mai chiamare /login. Lancia piuttosto che tornare nullo, perché trenta chiamanti assumere un id non nullo e sarebbe NPE da qualche altra parte completamente; login e l'autosession percorso catturarlo e modellare una risposta pulita. - FakeAccountGuard: due livelli di proposito. Il controllo del conto unico è UNCACHED (è il backup i cancelli duri, dove una risposta stante significa che un account contrassegnato continua a entrare); il id imposta sono memorizzati in cache per 60s (retro filtro di lettura, dove il caso peggiore è un org sintetico in un elenco per meno di un minuto). Falli aperti — nascondere una manciata di righe non è valore 500ing un elenco org — e NON memorizza un guasto, quindi un blip non diventa un minuto della bandiera silenziosamente non funziona. - OrgObjectStorageSweep: smette di istantanee org sintetici. Qui c'era il denaro: le istantanee sono scritte per org al giorno per sempre, e cinque org abbandonati avevano già diventare il ~9% di quel tavolo. Un account che non può accedere non fa nulla sul lavoro piattaforma continua a fare per suo conto. - FakeAccountController: flag, unflag, list — dietro MANAGE ORGANIZATIONS piuttosto che un nuova piattaforma destra, perché la piattaforma di kamo-internalRightCoverage test afferma il diritto contro le superfici rese della console. Revokes live sessioni su flagging, dal i cancelli sono su MINTING una sessione, non su utilizzando uno; rifiuta di contrassegnare l'Utente del Sistema, che renderebbe la piattaforma incapace di entrare qualsiasi bambino org. - I buchi... - /Registrati non legga mai '***Token`. Il registro UI ha sempre risolto un Capcha sfidare e postato il risultato; grep per il campo in tutta Java non ha restituito nulla. Il widget era nel browser e il endpoint era aperto. Ora verificato, e FAIL CLOSED — asimmetrico con login di proposito: il login può verificare solo un carico di pagamento quando uno è presente, perché il client mobile non invia nessuno e richiederlo ci si blocca utenti reali fuori. La registrazione ha esattamente un cliente e già invia il token. - CapchaVerificationService ha restituito TRUE quando `capcha.service-url` era unset, quindi una configurazione l'omissione era indistinguibile da una sfida risolta. Ora rifiuta, dietro `capcha.allow-unconfigured` (default false) per le piste locali. Nessun cambiamento di produzione — il la proprietà è impostata in kamowssecurity-config — ma il bypass latente è andato. - POST /org non aveva limiti di tasso di alcun tipo. Ora tappato per ACCOUNT (non per IP) una chiave IP sarebbe punire tutti dietro un NAT aziendale). Deliberatamente generoso: un vero cliente creato tre org in cinque e mezzo minuti, due con lo stesso nome e alias, mentre Sto lavorando al mago. Un limite stretto li avrebbe bloccati. Conta i tentativi, non successi, e non si apre su un outage Redis. - L'org alias non ha avuto alcun controllo di unicità su questo percorso — solo il dominio ha fatto, ecco perché quattro live orgs condividono "acme-corp" e perché il creatore ha variato solo il dominio ogni volta: era l'unico campo che il server avrebbe rifiutato. Ora un 409, indirizzato al fornitore di sicurezza perché `(security provider id, alias)` è la coppia di login risolve un host web-alias su. - REGISTRAZIONE / REGISTRAZIONE REGETTO / EMAIL VERIFIED / ORG CREATED sono ora scritti con IP e user-agent. Ogni regola di rilevamento chiavi fuori eventi di login, quindi l'intero registro imbuto seduto al di fuori del campo visivo del motore di rilevamento. Decisamente NON fatto, avendo controllato: il login non è fatto ***-strict (rompe il mobile app, ha bisogno di un rilascio coordinato); i domini di posta elettronica monouso non sono bloccati (una vera segnaletica del cliente da proton.me e una regola ingenua "non un fornitore mainstream" blocca reale persone); nessun blocco auto-contenuto (il segnale comportamentale più forte — nomi org duplicati creati minuti separati — corrisponde a un cliente reale esattamente). Schema prerequisito già soddisfatto: KamoInitializer applicato users.is fake prima spinta condivisa-lib, verificata come `boolean NON NULL DEFAULT false` con il suo indice parziale, e re-ran idempotently senza schiarire la bandiera.