pular para o conteúdo
~$ rebootworks
segurança

as 14 coisas que a gente confere antes de dar um site por entregue

·8 min de leitura·Dominick Brasileiro

a revisão de segurança que a gente roda em toda entrega antes de ir pro ar, escrita pra quem não é especialista conseguir rodar também.

percorrendo uma checklist item por item

Todo site que a gente entrega é atacado pela gente mesma antes de ser dado como pronto. A gente passa pela lista abaixo na mão, em vez de só apontar um scanner e esperar. Está incluso no preço, porque entregar algo que qualquer um derruba não é trabalho terminado.

Não precisa ser especialista pra percorrer essa lista junto com o seu desenvolvedor. E se você tem um site no ar hoje que nunca passou por isso, é coisa de uma tarde de trabalho.

Acesso e identidade

  1. Um usuário consegue ver os dados de outro só trocando um número na URL? Entre com duas contas e tente. É a falha grave mais comum que a gente encontra, e quase sempre está num endpoint de fatura, pedido ou documento que confere se você está logado, mas nunca confere quem você é.
  2. A área administrativa checa o perfil do usuário em toda rota, inclusive na API? Esconder o link não é controle. Chame o endpoint administrativo direto, logado como usuário comum, e veja o que volta.
  3. Os tokens de redefinição de senha expiram, e valem só uma vez? Peça uma redefinição, espere um dia, use o link antigo. Depois use o mesmo link duas vezes.
  4. Existe autenticação em dois fatores nas contas administrativas, e ela é obrigatória? Disponível mas opcional é o mesmo que desligada.
  5. Quem sai da empresa perde acesso em todos os lugares? Pegue o último desligamento e confira um por um: email, console da nuvem, git, hospedagem, banco de dados, gerenciador de senhas, painéis de terceiros.

Entrada e saída

  1. As consultas ao banco são parametrizadas em todo lugar? Procure concatenação de string dentro das consultas. Cada ocorrência é um problema até que se prove o contrário.
  2. O conteúdo enviado pelo usuário é escapado na hora de exibir? Cole <img src=x onerror=alert(1)> em todo campo que aparece de volta na tela, inclusive nomes, observações e nomes de arquivo.
  3. Os uploads são restritos pelo tipo real do conteúdo, pelo tamanho e pelo lugar onde ficam guardados? Checar só a extensão é fácil de burlar. Arquivo enviado nunca pode ser executável e nunca pode ficar na raiz do site.
  4. Existe limite de requisições no login, na redefinição de senha e em qualquer endpoint que dispara email ou custa dinheiro? Sem isso, testar senhas vazadas em massa e estourar a sua fatura sai de graça.

Segredos e configuração

  1. Tem credencial no histórico do git? Os arquivos atuais não contam a história toda, então procure no histórico também. Se achar alguma, trocar a chave importa mais do que apagar o commit.
  2. Buckets de armazenamento, portas de banco de dados e painéis administrativos estão privados? Backup em bucket público é um clássico, e entrega tudo de uma vez só.
  3. As páginas de erro são genéricas em produção? Stack trace, versão de framework e erro de SQL são reconhecimento de graça pra quem está atacando.

Transporte e dependências

  1. HTTPS é obrigatório em todo lugar, com HSTS, cookies seguros e uma Content-Security-Policy que faça sentido? Confira se o redirecionamento acontece também no www e no domínio sem prefixo.
  2. As dependências estão atualizadas, e tem alguma coisa de olho nelas? Rode uma auditoria hoje, depois automatize. A maioria das invasões de verdade entra por uma vulnerabilidade conhecida num pacote que ninguém atualizou.

E duas que não estão na lista, mas deviam estar

Você restaurou um backup recentemente? Backup que nunca foi restaurado é uma hipótese. Teste a restauração, cronometre e anote quanto tempo levou.

Você sabe pra quem ligar às 11 da noite? Deixe escrito, com antecedência: quem corta os acessos, quem fala com os clientes, quem decide se o site sai do ar. O meio de um incidente é a pior hora pra descobrir isso.

O que isso não cobre

Isso é uma checagem básica antes do lançamento, não um pentest. Não vai encontrar abuso de lógica de negócio, exploits encadeados, nem nada que exija esforço criativo e demorado contra a sua aplicação em particular, e é dessa categoria que vem a maioria dos vazamentos. Trate como o piso, não como o teto.


Quando você quiser o teto, a nossa frente de segurança roda pentests completos com escopo fechado, um relatório que a sua diretoria consegue ler, e um reteste grátis depois que você corrigir o que foi apontado. Peça um escopo.