misconfiguration
8 artigos com esta tag
Segurança do Django — uma referência de hardening de produção
O Django é 'baterias incluídas' com 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 é uma base sólida, 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.
Segurança do ASP.NET Core — uma referência de hardening de produção
O ASP.NET Core é uma fundação madura e sólida, 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.
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 buraco. 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) — a armadilha da configuração de proxy confiável
XFF é um cabeçalho forjável pelo cliente. Um scanner cego esconde sondagens de injeção em um XFF falsificado; 'confiar em todos os proxies (curinga)' o deixa passar. Patch = higienizar o cabeçalho de IP na fronteira; correção raiz = confiar nos proxies certos (ou em nenhum). Impacto zero ainda deixou uma configuração a corrigir.
O .env de apps Laravel era legível pelo mundo inteiro — o erro mais comum de hospedagem compartilhada
A causa: o app inteiro ficava sob a raiz web; só o public/ deveria estar visível. Corrija em três passos — primeiros socorros com .htaccess, rotacione chaves, reestruture — depois previna com processo.