Duas camadas de verificação
Combinamos revisões internas em que atacamos a nós mesmos com uma avaliação externa independente.
Revisão adversarial interna
Equipes independentes sondaram o código com cenários de ataque reais em várias rodadas e fecharam as descobertas de forma estrutural nas camadas de banco de dados e servidor.
Revisão externa — AEGISonar
Uma avaliação externa independente da nossa superfície de ataque e das vulnerabilidades web pelo AEGISonar da WebEASM.
Revisão adversarial interna — como fizemos
Não foi “programamos com cuidado” — nós realmente tentamos invadir. Equipes independentes, com metodologias diferentes, revisaram o código em paralelo em várias rodadas, e cada descoberta só foi confirmada após tentativas independentes de refutar que ela fosse alcançável.
Nosso método
Cenários de ataque que testamos
Tentamos de fato os ataques abaixo e verificamos que eles são bloqueados no nível do banco de dados e do código do servidor.
✓Burla do isolamento de tenants
Tentativas de ler ou gravar clientes, documentos ou solicitações de outro escritório. Não só leituras — as gravações (INSERT/UPDATE) também estão vinculadas à relação escritório↔cliente e são bloqueadas.
✓Escalada vertical de privilégios
Tentativas de subir de funcionário→proprietário ou de cliente→membro do escritório. As decisões de função e o aceite de convites são impostos no servidor e no banco de dados.
✓Sequestro de links de convite
Tentativas de aceitar um convite com um e-mail diferente. O e-mail de login precisa ser igual ao e-mail convidado.
✓Burla de MFA
Tentativas de acessar dados só com a senha. Depois que um fator é cadastrado, o banco de dados exige uma sessão aal2 (de dois fatores).
✓Abuso de retransmissão de notificações/e-mails e injeção de phishing
Tentativas de injetar links de login falsos pelas rotas de notificação. A identidade do remetente e os domínios dos links são fixados em valores confiáveis.
✓Abuso do funil de cadastro
Chamadas anônimas em massa à API de cadastro para derrubar o serviço ou ocupar endereços de escritórios. Bloqueado por roteamento via servidor, limites de taxa e vínculo com a sessão de pagamento.
✓Exposição de segredos, XSS, redirecionamentos abertos
Verificamos se segredos do servidor vazam para o navegador, se a entrada do usuário é executada como script e se os redirecionamentos podem ser abusados.
✓Falsificação de webhooks de SMS recebidos
Tentativas de falsificar webhooks de entrada para alterar o consentimento de SMS. Bloqueado pela verificação obrigatória de assinatura.
Os problemas reais confirmados foram fechados no nível das políticas do banco de dados e do código do servidor, a maioria antes da entrada de clientes reais.
Um limite honesto
Segurança é um processo contínuo que nunca está “pronto”. Nossas revisões internas se baseiam em análise estática e cenários, complementadas pela avaliação externa do AEGISonar. À medida que atendemos mais clientes, continuamos ampliando nossos testes. Em vez de alegar perfeição, escolhemos ser transparentes sobre o que verificamos e como.