- Shipped
- 19 de agosto de 2026 às 08:09 UTC
- Author
- Kamo
- Commit
- 19ddc01
Duas metades de um incidente. Uma conta registada, verificada num endereço descartável provedor, tomou uma sessão de auto-login e criou cinco organizações em três minutos e quarenta e dois segundos — quatro deles byte-identical "Acme Corp" linhas que diferem apenas em seus domínio. Ele produziu linhas ZERO em system access logs, então não há IP e nenhum usuário-agente Está registado. A fazer cumprir a bandeira. - Autenticação do Utilizador Serviço: `u.is fake = FALSE` entra em Um ouvinte. Todos os três identificadores de login – nome de usuário, e-mail de conta e caixa de correio principal re-searched by id — reutilizar essa projeção, então uma cláusula fecha todos os três e um quarto identificador adicionado mais tarde herda-o. Uma conta marcada é considerada inexistente e obtém o genérico "usuário não existe ou senha está incorreta"; uma mensagem que nomeia o A bandeira diria a um abusador exatamente o que mudar. - KSessionService.createSession: recusa-se totalmente. Esta é a cintura mais estreita no sistema para "que esta conta actue" — cada *** é cunhada aqui, por isso uma capa de portão login de senha, enter-as, SSO desktop, autenticação do dispositivo E o funil de registro auto-login pós-verificação, que é como a conta em questão tem uma sessão sem nunca chamar /login. Joga em vez de voltar nulo, porque trinta chamadas assumir um id não null e NPE em outro lugar inteiramente; login e a sessão automática caminho pegá-lo e moldar uma resposta limpa. - FakeAccountGuard: dois níveis de propósito. A conta única é UNCACHED (ele volta os portões rígidos, onde uma resposta defasada significa uma conta marcada ainda entra); o id define são guardados em cache por 60s (eles de volta ler filtragem, onde o pior caso é uma org sintética permanência em uma lista por menos de um minuto). Falha aberta — esconder um punhado de linhas não é vale 500 uma lista de orgs — e NÃO cache uma falha, então um blip não se torna Um minuto da bandeira silenciosamente não funciona. - OrgObjectStorageSweep: pára de fotografar orgs sintéticos. Era aqui que estava o dinheiro. instantâneos são escritos por org por dia para sempre, e cinco orgs abandonados já tinham tornar-se ~9% dessa tabela. Uma conta que não pode entrar não faz nada sobre o trabalho plataforma continua fazendo em seu nome. - FakeAccountController: flag, unflag, list — por trás MANAGEME ORGANIZAÇÕES em vez de um nova plataforma direita, porque plataforma kamo-internal do teste RightCoverage assevera o direito ajuste contra as superfícies renderizadas da consola. Revoga sessões ao vivo sobre sinalização, desde o gates estão em MINTING uma sessão, não em usar uma; recusa-se a marcar o Usuário do Sistema, que tornaria a plataforma incapaz de entrar em qualquer org infantil. Os buracos... - O registo nunca lê '***Token'. A interface de registro sempre resolveu um Capcha desafio e postou o resultado; grep para o campo em todo o Java não retornou nada. O widget estava no navegador e o endpoint estava aberto. Agora verificado, e falhar FECHADO — assimétrico com login de propósito: o login só pode verificar uma carga útil quando se está presente, porque o cliente móvel não envia nenhum e rígido-requirendo-lo lá iria bloquear usuários reais fora. O registro tem exatamente um cliente e já envia o token. - CapchaVerificationService retornou TRUE quando `capcha.service-url` foi desativada, então uma configuração a omissão era indistinguível de um desafio resolvido. Agora rejeita, para trás `capcha.allow-unconfigured` (padrão false) para corridas locais. Nenhuma alteração da produção — a propriedade está definida em kamowssecurity-config — mas o bypass latente desapareceu. - POST /org não tinha limite de taxa de qualquer tipo. Agora com o título por CONTA (não por IP — uma chave IP puniria todos por trás de uma empresa NAT). Deliberadamente generoso: um cliente real criou três orgs em cinco minutos e meio, dois com o mesmo nome e apelido, enquanto A trabalhar no feiticeiro. Um limite apertado os teria bloqueado. Conta tentativas, não sucessos, e falhas abertas em uma falha Redis. - O alias org não tinha verificação de singularidade neste caminho — apenas o domínio fez, razão pela qual quatro orgs ao vivo compartilham "acme-corp" e por que o criador variou apenas o domínio de cada vez: era o único campo que o servidor rejeitaria. Agora um 409, escopo para o provedor de segurança porque `(security provider id, alias)` é o login par resolve um host web-alias ligado. - REGISTO/REGISTRAÇÃO REJECTO / EMAIL VERIFIADO / ORG CREADO IP e usuário-agente. Todas as chaves de regras de detecção fora de eventos de login, então todo o registro O funil sentou-se fora do campo de visão do motor de detecção. Deliberadamente NÃO feito, tendo verificado: login não é feito ***-strict (quebra o celular aplicativo, precisa de uma liberação coordenada); domínios de e-mail descartáveis não são bloqueados (um real o cliente assina de proton.me, e uma regra ingênua "não um provedor mainstream" bloqueia real Não há auto-bloqueamento de conteúdo (o sinal comportamental mais forte) nomes de org duplicados criados a minutos de distância — corresponde exatamente a um cliente real). Pré-requisito do esquema já satisfeito: KamoInitializer applicated users.is fake before the compartilhamento-lib push, verificado como `boolean NOT NULL DEFAULT false` com seu índice parcial, e Re-ran idempotently sem limpar a bandeira.