Uma revisão de segurança que dá para fazer em uma tarde

A maioria dos times não pula revisões de segurança porque não se importa. Pula porque imagina uma semana de especialistas e um relatório numa língua que ninguém fala. Essa versão existe e tem seu lugar. Mas a maioria das brechas que vi em auditorias teria sido pega por uma tarde focada com a base de código, um navegador e um cliente de banco de dados. Aqui está a tarde.

O checklist

• Autenticação em toda rota: liste todo endpoint, marque quais exigem usuário logado e tente os não marcados sem sessão
• Autorização em todo objeto: logue como um usuário, pegue um ID que pertence a outro e requisite, em todo endpoint que aceita ID
• Segredos: busque no histórico do repositório, em arquivos de ambiente, em logs e em respostas de erro por chaves, tokens e senhas
• Entrada na fronteira: encontre todo lugar em que entrada do usuário chega a uma query, um shell, um caminho de arquivo ou um template HTML, e confira o que valida
• Dependências: rode a ferramenta de auditoria do seu gerenciador de pacotes e leia os achados críticos, não a contagem
• Headers e cookies: confira que cookies de sessão são HttpOnly e Secure, e que os headers básicos de segurança estão definidos
• Limites de taxa: encontre o login, a recuperação de senha e qualquer endpoint que envie e-mail ou dinheiro, e confira se algo limita a frequência de chamadas

Para onde a tarde vai de verdade

Duas dessas sete verificações vão consumir a maior parte do tempo e produzir a maior parte dos achados: autorização em todo objeto e entrada na fronteira. A primeira é tediosa e mecânica, que é exatamente por que ninguém faz. Pegue um ID real do usuário A, logue como usuário B e bata em todo endpoint que aceita ID: ver, editar, apagar, exportar, baixar. Na maioria dos sistemas que audito, pelo menos um endpoint confere que você está logado e esquece de conferir que a coisa que você pediu é sua. Essa única classe de bug, a referência direta insegura a objeto, já expôs mais dados de clientes do que todos os exploits espertos juntos.

A segunda verificação é leitura. Siga cada valor controlado pelo usuário de onde ele entra até onde é usado. Se chega a uma string SQL por concatenação, a um comando de shell, a um caminho de arquivo ou a um template sem escape, você encontrou algo. Queries parametrizadas e um motor de template que escapa por padrão eliminam a maior parte disso, e leva vinte minutos confirmar se a base de código os usa de forma consistente ou 'quase sempre'.

O que você vai encontrar nos logs

A verificação de segredos é a que mais surpreende os times. Busque nos logs por 'password', 'token', 'authorization' e 'card'. Depois busque no histórico do git, não só na árvore atual, pelas mesmas palavras. Depois provoque um erro de propósito e leia a resposta que o cliente recebe. Já encontrei strings de conexão completas do banco em stack traces devolvidos ao navegador, e chaves de API commitadas na primeira semana de um projeto e 'removidas' na segunda, ainda no histórico para qualquer um com acesso de clone.

O que isto não é

Isto não é um pentest e não vai encontrar uma falha criptográfica sutil nem uma condição de corrida no tratamento de sessão. É um piso, não um teto. Mas é um piso contra o qual a maioria dos sistemas nunca foi conferida, e a diferença entre um sistema que passou por esta tarde e um que não passou é a diferença entre um atacante precisar de habilidade e um atacante precisar de um navegador.

Torne recorrente

A tarde vale mais se acontece todo trimestre, ou a cada funcionalidade grande. Escreva as sete verificações num documento, designe uma pessoa, coloque no calendário. Um time que faz isso ainda vai ter problemas de segurança. Não vai ter os vergonhosos, e os vergonhosos são os que acabam no noticiário.