- Verschifft
- 19. August 2026 um 08:09 UTC
- Autor
- Kamo
- Ausschuss
- 19ddc01
Zwei Hälften von einem Vorfall. Ein Konto registriert, überprüft eine Adresse an einem Einweg Anbieter, nahm eine Auto-Login-Sitzung und erstellt fünf Organisationen in drei Minuten und 42 Sekunden - vier von ihnen schiffsidentisch "Acme Corp"-Reihen, die sich nur in ihrem Domain. Es produzierte ZERO-Zeilen in system_access_logs, so dass es keine IP und keinen User-Agent gibt auf Rekord für jede davon. Die Flagge durchsetzen ************ - UserAuthenticationService: "u.is_fake = FALSE" geht in ACCOUNT_QUERY_PREFIX, nicht in ein Anrufer. Alle drei Login-Kennzeichen - Benutzername, Konto-E-Mail und das Primär-Mail-Postfach re-lookup keyed by id - Wiederverwendung dieser einen Projektion, so dass eine Klausel alle drei schließt und Die vierte Kennung, die später hinzugefügt wurde, erbt sie. Ein beflaggter Account liest sich als nicht existent und bekommt das generische "Benutzer existiert nicht oder Passwort ist falsch"; eine Nachricht, die die Flagge würde einem Täter genau sagen, was zu ändern. - KSessionService.createSession: lehnt sich direkt ab. Dies ist die schmalste Taille in der System für "kann dieses Konto handeln" - jeder *** wird hier geprägt, so dass ein Tor abdeckt Passwort-Anmelden, Enter-as, Desktop SSO, Gerät auth UND der Registertrichter Post-Verifikation Auto-Login, das ist, wie das Konto in Frage bekam eine Sitzung ohne jemals /login anzurufen. Werfen statt zurück null, weil dreißig Anrufer Übernahme einer Non-Null-ID und würde NPE ganz woanders; Login und die Auto-Session Pfad fangen Sie es und formen Sie eine saubere Antwort. - FakeAccountGuard: zwei Stufen absichtlich. Der Single-Account-Check ist UNCACHED (es geht zurück die harten Tore, wo eine abgestandene Antwort bedeutet, dass ein markiertes Konto noch hereinkommt); die ID-Sets sind für 60er Jahre zwischengespeichert (sie lesen Sie Filterung zurück, wo der schlimmste Fall ist eine synthetische Org Verweilen in einer Liste für weniger als eine Minute). Fails offen - eine Handvoll Reihen zu verstecken ist nicht im Wert von 500ing eine Org-Liste - und nicht Cache einen Ausfall, so dass ein Blip nicht werden eine Minute der Flagge still nicht funktioniert. - OrgObjectStorageSweep: stoppt Snapshotting synthetische orgs. Hier war das Geld: Schnappschüsse werden für immer pro Org pro Tag geschrieben, und fünf verlassene Orgs hatten bereits werden 9% dieser Tabelle. Ein Konto, das sich nicht einloggen kann, tut nichts über die Arbeit der Plattform weiterhin in ihrem Namen zu tun. - FakeAccountController: Flag, unflag, list - hinter MANAGE_ORGANIZATIONS statt einer neue Plattform rechts, denn kamo-internals platformRightCoverage-Test behauptet das Recht gegen die gerenderten Oberflächen der Konsole gesetzt. Entrufen Live-Sitzungen auf Beflaggung, da die Gates sind auf MINTING eine Sitzung, nicht auf die Verwendung eines; weigert sich, den Systembenutzer zu markieren, die würde die Plattform nicht in der Lage, ein Kind org geben. Die Löcher **************** - / registrieren Sie nie lesen "***Token". Das Register UI hat immer ein Capcha gelöst Herausforderung und veröffentlicht das Ergebnis; grep für das Feld über alle Java zurückgegeben nichts. Das Widget war im Browser und der Endpunkt war weit offen. Jetzt verifiziert, und FAIL GESCHLOSSEN - asymmetrisch mit Login absichtlich: Login kann nur eine Nutzlast überprüfen, wenn man vorhanden, weil der mobile Client sendet keine und hart ernorgt es würde sperren echte Benutzer aus. Die Registrierung hat genau einen Client und der ist bereits der Token. - CapchaVerificationService hat TRUE zurückgegeben, wenn "capcha.service-url" nicht gesetzt wurde, also eine config Ausgelassenheit war von einer gelösten Herausforderung nicht zu unterscheiden. Jetzt lehnt ab, hinter "capcha.allow-unconfigured" (Standard falsch) für lokale Läufe. Keine Produktionsänderung Die Immobilie ist in kamowssecurity-config gesetzt, aber die latente Umgehung ist weg. - POST /org hatte keine Tarifbegrenzung. Jetzt gedeckelt pro ACCOUNT (nicht pro IP - ein IP-Schlüssel würde jeden hinter einem korporativen NAT bestrafen). Bewusst großzügig: ein echter Kunde erstellt drei Orgs in fünfeinhalb Minuten, zwei mit dem gleichen Namen und Alias, während den Assistenten ausarbeiten. Eine enge Begrenzung hätte sie blockiert. Zählt Versuche, nicht Erfolge, und scheitert offen an einem Redis Ausfall. - Der Org-Alias hatte KEINE Einzigartigkeit auf diesem Pfad - nur die Domain tat es, weshalb vier lebende Orgs teilen "acme-corp" und warum der Schöpfer variierte nur die Domain jedes Mal: es war das eine Feld, das der Server ablehnen würde. Jetzt ein 409, zum Sicherheitsanbieter weil "(security_provider_id, alias) " ist das Paar Login löst einen Web-alias Host auf. - REGISTRATION / REGISTRATION_REJECTED / EMAIL_VERIFIED / ORG_CREATED sind jetzt mit IP und User-Agent. Jede Erkennung Regel Schlüssel von Login-Ereignissen, so dass das ganze Register Trichter saß außerhalb des Sichtfeldes der Erkennungsmaschine. Bewusst NICHT getan, überprüft: Login ist nicht ***-streng (bricht das Handy App, braucht eine koordinierte Freigabe); Einweg-E-Mail-Domains werden nicht blockiert (eine echte Kunde meldet sich bei proton.me an, und eine naive "kein Mainstream-Anbieter"-Regel blockiert real Personen); kein Content-Scoring-Autoblock (das am stärksten aussehende Verhaltenszeichen duplizierten org-Namen erstellt Minuten auseinander - passt ein echter Kunde genau). Schema-Voraussetzung bereits erfüllt: KamoInitializer angewendet user.is_fake vor der Shared-lib Push, verifiziert als "boolean NOT NULL DEFAULT false" mit seinem Teilindex, und re-lief idempotently, ohne die Flagge zu löschen.