misconfiguration
10 artigos com esta tag
Exposição pública de armazenamento em nuvem: quando os dados podem vazar mesmo com o Block Public Access ativado
Vazamentos de bucket vêm de configuração, não de ataque. A frase que importa na documentação: as configurações de bloqueio de acesso público não alteram as políticas nem as ACLs existentes — as configurações públicas continuam por baixo do bloqueio, e remover o bloqueio restaura o acesso público. Então a meta não é "o bloqueio está ativado", mas "nada é público mesmo com o bloqueio desligado". Aplique no nível da conta, porque uma política de bucket pode dar a alguém a capacidade de desligar um bloqueio no nível do bucket. E "público" tem uma definição mais ampla do que as pessoas imaginam.
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 vêm de um pequeno conjunto de padrões que se repetem, e os padrões ficam mais claros organizados por crença do que por tecnologia. São quatro: o padrão deve ser seguro (nada foi configurado), o que não é usado deve ser inofensivo (nada foi fechado), a gente perceberia (nada é observável) e a entrada validada deve ser segura (muita coisa foi delegada à entrada). Nenhum deles exige conhecimento técnico profundo para corrigir — exige o hábito de verificar. Veja o que olhar em cada um.
Segurança do ASP.NET Core — uma referência de hardening de produção
O ASP.NET Core é um framework maduro e estável, mas os incidentes vêm das configurações. Esta é uma referência de trabalho: (1) um checklist de hardening ordenado por prioridade (P0–P2), (2) orientação por área — não exponha erros detalhados / a Developer Exception Page em produção, externalize segredos (User Secrets/env/Key Vault), CVEs de dependências NuGet, autorização ([Authorize], fallback default-deny, baseada em recurso/proprietário), over-posting (DTOs/[Bind]), desserialização insegura (evite BinaryFormatter), HTTPS/headers/antiforgery, SSRF e (3) um checklist de autoverificação. Só defensivo — sem passos de ataque.
Segurança do Django — uma referência de hardening de produção
O Django traz muitos padrões seguros (ORM, CSRF, auto-escapamento, auth), mas os incidentes vêm das configurações. Esta é uma referência de trabalho: (1) um checklist de hardening ordenado por prioridade (P0–P2), (2) orientação por área — DEBUG=False + ALLOWED_HOSTS, externalizar o SECRET_KEY, CVEs de dependências pip, config de segurança de produção (SECURE_SSL_REDIRECT/HSTS/SESSION_COOKIE_SECURE, etc.), autorização (escopo de proprietário), injeção e saída (raw/extra, mark_safe), CSRF/sessões/admin, SSRF/uploads e (3) um checklist de autoverificação. Só defensivo — sem passos de ataque.
Segurança por framework — defesas específicas para a tecnologia que você usa
Seja qual for o framework que você usa, os *tipos* de fraqueza que os atacantes exploram são em grande parte os mesmos (controle de acesso, segredos, injeção, CVEs de dependências, configuração incorreta). O que muda são os 'padrões perigosos' e 'o ponto mais visado' de cada framework. Este site oferece, por framework, as falhas padrão e os passos de hardening. Comece pelo capítulo da tecnologia que você de fato usa.
Segurança do Laravel — uma referência de hardening para produção
Os padrões do Laravel são fortes; os incidentes em produção vêm da configuração e da operação. Esta é uma referência de trabalho: (1) um checklist de hardening por prioridade (P0–P2), (2) uma tabela de padrões perigosos, (3) orientação por área — segredos/APP_KEY, config de produção (APP_DEBUG/cache), autorização (Policy/Gate, Mass Assignment), injeção/saída (binding do Eloquent, Blade), sessões/CSRF/cookies, uploads, HTTPS/cabeçalhos/limitação de taxa, CVEs de dependências do Composer, e (4) um checklist de autoverificação. Apenas defensivo — sem passos de ataque.
Segurança do Spring Boot — uma referência de hardening para produção
O Spring Boot é um framework estável, mas os incidentes vêm de dependências, configuração e autorização. Esta é uma referência de trabalho: (1) um checklist de hardening priorizado (P0–P2), (2) orientação por área — CVEs de dependências (classe Log4Shell, julgue pela versão em execução), configuração de produção e segredos externalizados, autorização no Spring Security (negação por padrão/segurança em nível de método/checagens de dono), redução da exposição do Actuator/gerenciamento, desserialização insegura, injeção, cabeçalhos/CSRF/sessão, SSRF, e (3) um checklist de autoverificação. Apenas defensivo — sem passos de ataque.
Você deixou um arquivo de segredo em um diretório público? Audite seu webroot
Qualquer coisa no seu webroot pode ser baixada pela URL por qualquer um. Um JSON de token/credenciais esquecido, um .env ou um backup significam exposição instantânea — e se veio de um template compartilhado, todo site tem o mesmo arquivo. Correção: coloque no diretório público só o que pode ser compartilhado, mantenha segredos fora do webroot com permissão 600 e, ao achar um, audite todos os sites e hosts.
O que é a falsificação de X-Forwarded-For (XFF): configuração incorreta de proxy confiável e como se defender
XFF é um cabeçalho forjável pelo cliente. Um scanner indiscriminado coloca sondagens de injeção em um XFF falsificado, e uma configuração de 'confiar em todos os proxies (curinga)' o deixa passar. Correção de curto prazo: higienizar o cabeçalho de IP na fronteira. Correção da causa: confiar só nos proxies certos (ou em nenhum). Impacto zero ainda deixou uma configuração a corrigir.
Um caso em que o .env do Laravel ficou legível publicamente: um erro de posicionamento em hospedagem compartilhada e como corrigi-lo
A causa: o app inteiro ficava sob a raiz web; só o public/ deveria estar visível. Corrija em três passos — um bloqueio temporário com .htaccess, rotacione chaves, reestruture — depois previna com processo.