Guias de Segurança
4 erros comuns de segurança: configurações padrão, serviços esquecidos, falta de monitoramento e confiança excessiva na validação de entrada
Incidentes reais raramente envolvem ataques exóticos. Organizadas pela suposição por trás delas, as causas se resumem a quatro crenças — e cada uma já foi verdadeira um dia, e é por isso que ninguém as revisa.
Coloque lado a lado os incidentes que de fato acontecem e as técnicas de ataque exóticas quase não aparecem. O que aparece é um pequeno conjunto de padrões que se repetem, e esses padrões ficam mais claros quando organizados não pela tecnologia, mas pela suposição por trás deles.
① A suposição de que o padrão é seguro (nada foi configurado)
Padrões escolhidos para facilitar o desenvolvimento
erros detalhados · telas de administração acessíveis · permissões amplas
↓ publicados sem alteração
Mostra detalhes internos a quem olhar
estrutura, caminhos, versões e valores internos ficam legíveis
- Saída de depuração ligada em produção
- As páginas de erro expõem variáveis de ambiente, caminhos de arquivo ou stack traces? Abra uma URL que não existe e veja com os próprios olhos o que volta. Os detalhes de cada framework estão nos guias por framework
- Telas de administração acessíveis
- Ferramentas de gerenciamento de banco de dados e consoles de administração acessíveis pela internet. Não confie só na autenticação — acrescente restrição de IP ou bloqueio no nível da rede
- Cabeçalhos ausentes ou copiados de uma lista antiga
- Veja quais cabeçalhos ainda importam e quais não. Um cabeçalho obsoleto pode causar dano se você o adicionar
- Armazenamento fraco mantido
- Armazenamento de senhas como descrito em hash e salt. "Está criptografado" não descreve um esquema de armazenamento
- As atualizações pararam
- Rodar uma linguagem, framework ou CMS depois do fim do suporte. Veja monitoramento automático de dependências e o que o fim do suporte significa na prática
② A suposição de que o que não é usado é inofensivo (nada foi fechado)
Boa parte da sua superfície de ataque vem de coisas que você parou de usar, mais do que das coisas que você construiu. Quando algo deixa de ser usado, sai do monitoramento e da revisão sem ninguém perceber.
- Segredos deixados num diretório público
.env, backups, dumps, arquivos de configuração. o que nunca deve ficar num diretório público / onde colocar em hospedagem compartilhada- Armazenamento ainda público
- Ligar o bloqueio não apaga a política pública existente. buckets públicos
- Registros de DNS pendentes
- Apague um recurso sem apagar a entrada de DNS e qualquer pessoa pode registrar o nome e tomar o subdomínio. tomada de subdomínio
- Caminhos de cadastro e de administração deixados abertos
- O cadastro aberto ainda está ativo? Meça por HTTP em vez de ler a configuração (autenticação vs. autorização). Não deixe uma URL adivinhável como a única coisa que "esconde" uma página
- Contas que você achava canceladas
- Cancelar um serviço e apagar a conta são coisas diferentes, e os dados ficam até você apagar. quando o seu provedor de hospedagem é invadido
- Chaves, tokens e permissões antigos
- Contas de colegas que saíram, tokens sem validade, escopos amplos demais. chaves SSH e privilégio mínimo / gerenciadores de senhas
Não limite o inventário ao que está rodando
Limite a revisão a "coisas em uso agora" e esse padrão simplesmente não pode ser encontrado. Inclua tudo o que você já criou — subdomínios, contas, chaves, buckets, ambientes de homologação, assinaturas de terceiros. Algo que você parou de usar continua sendo um ativo até ser apagado. Como montar a lista: o checklist de inventário de ativos.
③ A suposição de que você perceberia (sem monitoramento)
O dano é determinado menos pela invasão em si do que por quanto tempo ela continua antes de alguém perceber. E a maioria dos ambientes não tem nenhum mecanismo para perceber.
O estado comum
・Os logs de acesso existem, mas ninguém os lê
・Não há log de auditoria das tentativas de autenticação (então não dá para reconstruir depois "o que foi visto")
・Os limites de taxa estão configurados, mas ninguém vê quando eles disparam
・O estado público é a combinação de várias camadas, então nenhuma delas sozinha responde à pergunta
O resultado é só conseguir dizer "não sabemos" sobre se algo aconteceu.
O mínimo que vale a pena ter
・Uma notificação de novo cadastro de usuário (um sinal basta para pegar o caso estranho)
・Um registro de sucessos e falhas de autenticação, com prazo de retenção
・Monitoramento automático de vulnerabilidades em dependências (pessoas não conseguem acompanhar isso → osv-scanner)
・Um registro das vezes em que o limite foi atingido, e um alerta quando houver um pico (limitação de taxa e controle de abuso)
Você não precisa de tudo. Um jeito de perceber problemas que funcione é o que impede um incidente de se arrastar.
Sem logs, a resposta honesta é "não sabemos", não "nada aconteceu"
O movimento mais perigoso na resposta a incidentes é ler a ausência de registros como prova de que nada ocorreu. Sem registros, a única afirmação sustentável é "não sabemos" — e, nesse caso, siga supondo que houve comprometimento e troque tudo o que possa ter sido exposto. O mínimo para organizações está em a linha de base de segurança para organizações.
④ A suposição de que a entrada validada é segura
A pergunta real sobre uma entrada não é "este valor está correto", mas "quanto eu deixei esta entrada decidir". Quanto mais decisões você entrega, menos a validação consegue acompanhar.
- Só o valor
- Entrada comum. Verificações de tamanho, formato e faixa funcionam — o lado seguro
- A estrutura também
- Designs que aceitam um objeto aninhado inteiro e o mesclam. prototype pollution
- O tipo também
- Formatos que reconstroem objetos. O ataque dá certo antes de as suas verificações de valor rodarem. desserialização insegura
- Onde vai parar
- Uploads que acabam num lugar onde podem ser executados. vulnerabilidades de upload de arquivos
- Quem é a requisição
- Confiar num cabeçalho da requisição para decidir a identidade do cliente. falsificação do X-Forwarded-For e proxies confiáveis
Contar as decisões que você entregou mostra os lugares perigosos. E a causa de fundo costuma ser a mesma: tentar resolver na validação o que deveria ser resolvido na estrutura. Mudar o formato que você aceita é mais confiável do que adicionar mais uma verificação.
Fazendo em ordem
Veja como a produção aparece de fato (①)
Uma URL que não existe, uma requisição que dá erro, os caminhos de administração — faça a requisição por HTTP e veja o que volta. O ponto é ler a saída, não a configuração. Os cabeçalhos podem ser medidos de uma vez com o verificador de cabeçalhos.
Anote tudo o que você já criou (②)
Subdomínios, contas, chaves, buckets, serviços de terceiros. O truque é não filtrar por "ainda está rodando". Monte a lista com o checklist de inventário de ativos e leve os itens sem uso até a exclusão (não só a desativação).
Configure exatamente um jeito de perceber problemas (③)
Tentar montar um monitoramento completo costuma terminar em nenhum. Comece com um — notificação de novos cadastros, um pico de logins com falha ou e-mail de vulnerabilidades em dependências. Um, incluindo confirmar que ele realmente dispara (monitoramento configurado mas nunca verificado é monitoramento que você não tem).
Conte o que as suas entradas podem decidir (④)
Escreva se os dados externos decidem só valores, ou também estrutura, tipo e destino. Qualquer lugar em que decidam mais do que valores é um ponto de alta prioridade para mudar.
Transforme as atualizações em mecanismo (para que o ① não volte)
O primeiro padrão volta com certeza se for deixado de lado. Colocar as atualizações de dependências e do framework sob monitoramento automático é a única resposta realista (primeiros passos com o osv-scanner / um guia prático de correção de CVEs). Um procedimento que só existe num documento é a primeira coisa pulada num dia corrido.
A visão deste site: as quatro já foram verdadeiras um dia
O que as quatro têm em comum é que cada uma foi correta em algum momento. Os padrões eram razoáveis durante o desenvolvimento; as coisas sem uso realmente não eram usadas; enquanto você era pequeno, de fato perceberia; e a validação de entrada já resolveu muitos problemas. É exatamente por isso que ninguém as revisa.
A nossa posição é perguntar periodicamente quando uma suposição antes correta deixou de ser correta. Essa verificação é mais barata e mais eficaz do que adicionar mais tecnologia. E repare na diferença de natureza: um checklist diz o que fazer, mas não por que algo passou despercebido — e, se o motivo não mudar, a mesma coisa vai passar despercebida no mesmo lugar de novo.
Leia a seguir
- Em forma de passos: o checklist de segurança básica (pessoas e equipes pequenas) / a linha de base de segurança para organizações
- Inventário: o checklist de inventário de ativos
- A partir de casos reais: análises de incidentes (os mesmos padrões continuam aparecendo)
- Tendência: em 2026, os atacantes chegaram com credenciais mais vezes do que com exploits
FAQ
QPor onde devo começar em segurança?
Verificar com qual dos quatro padrões o seu ambiente combina funciona mais rápido do que aprender técnicas de ataque uma a uma. As configurações de produção ainda estão no padrão? Há algo ainda aberto que você criou e nunca fechou? Você perceberia se algo desse errado? Quanto você deixa a entrada externa decidir? Este artigo traz as verificações concretas de cada um e links para os artigos mais aprofundados.
QIsso vale para um site pessoal pequeno?
Os padrões são os mesmos; a ordem muda. Para uma pessoa ou uma equipe pequena, os dois que dão retorno primeiro são verificar os padrões (a saída de depuração está ligada em produção?) e inventariar o que nunca foi fechado (segredos num diretório público, subdomínios sem uso, contas paradas). A observabilidade exige estrutura e pode esperar — mas até um único sinal, como uma notificação de novos cadastros de usuários, reduz muito o tempo em que um problema passa despercebido.
QQual a diferença disso para um checklist?
Um checklist diz o que fazer; este artigo trata de por que as coisas passam despercebidas. Listar itens não ajuda se o motivo pelo qual eles passaram despercebidos continua o mesmo — a mesma coisa vai passar despercebida no mesmo lugar de novo. As quatro crenças já foram verdadeiras um dia, e é exatamente por isso que sobrevivem sem revisão. Quando quiser os passos concretos, siga os links para os artigos de checklist em cada seção.
QSó tenho tempo para um. Qual?
Corrija uma coisa no terceiro: conseguir perceber. Os dois primeiros viram incidentes se forem ignorados, mas sem o terceiro você não vai saber que um incidente aconteceu. O dano é decidido menos pela invasão do que por quanto tempo ela continua sem ser percebida. Manter um log, adicionar uma notificação, fazer um inventário por mês: qualquer um desses é o investimento de maior retorno para impedir que um incidente se arraste.