framework
9 artigos com esta tag
Segurança do ASP.NET Core — erros em produção, segredos e autorização
O ASP.NET Core é uma base madura e sólida, mas os incidentes vêm das configurações. Os três grandes: (1) expor erros detalhados / a Developer Exception Page em produção (vazamento de informação interna), (2) segredos fixos em appsettings.json (use User Secrets / variáveis de ambiente / Key Vault), (3) atributos de autorização ausentes ([Authorize]). Além de desserialização insegura (BinaryFormatter, etc.), over-posting no model binding (limite com DTOs/[Bind]) e CVEs de dependências NuGet. Defesas: oculte erros detalhados em produção, carregue segredos de fora da config, torne a autorização explícita.
Segurança do Django — DEBUG, SECRET_KEY e autorização
O Django é 'baterias incluídas' com padrões seguros (ORM, CSRF, auto-escapamento de templates, auth) e é sólido quando configurado corretamente. Mas os incidentes vêm das configurações. Os três grandes: (1) DEBUG=True em produção expondo configurações, variáveis de ambiente e segredos na página de erro, (2) um SECRET_KEY vazado (a base para assinatura/sessões), (3) autorização rasa (verificações de is_staff/permission ausentes). Além de SQLi via raw()/extra() ou interpolação de string, desserialização insegura (pickle), ALLOWED_HOSTS não definido e CVEs de dependências (pip). Defesas: DEBUG=False em produção, SECRET_KEY do ambiente, autorização explícita.
Segurança do Express (Node.js) — as defesas que você mesmo adiciona
O Express é minimalista — ele traz quase nenhum recurso de segurança por padrão, então as defesas são as que o desenvolvedor adiciona. O essencial: (1) cabeçalhos de segurança (estilo helmet), (2) validação e sanitização de entrada, (3) autorização com escopo de proprietário, não apenas autenticação, (4) rate limiting (força bruta / DoS), (5) monitoramento de CVEs de dependências (npm) e correção rápida. Além de proteção contra SSRF em buscas de URL de saída e segredos mantidos em variáveis de ambiente, fora do código. A liberdade de um framework mínimo vem com a responsabilidade de defender.
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 — exposição de .env, APP_DEBUG e autorização
O Laravel entrega padrões razoavelmente seguros, mas a maioria dos incidentes vem da operação. As três grandes armadilhas: (1) .env ou arquivos de segredos acessíveis por URL a partir do diretório público, (2) APP_DEBUG=true em produção expondo variáveis de ambiente e informações de conexão na página de erro, (3) autorização ausente (login = autenticação, mas sem autorização com escopo de proprietário / Mass Assignment sobrescrevendo campos não intencionais). Defesas: segredos fora de public com permissão 600, debug desligado + cache de config em produção, autorizar com Policy/Gate, declarar $fillable.
Segurança do Next.js — Server Actions, variáveis de ambiente e CVEs de dependências
O Next.js traz padrões bastante seguros, mas os incidentes acontecem na fronteira servidor/cliente. Os três grandes: (1) exposição de variáveis de ambiente (uso incorreto de NEXT_PUBLIC_ ou envio de segredos server-only ao cliente), (2) autorização ausente em Server Actions / Route Handlers (autenticado mas sem escopo de dono), e (3) CVEs de dependências conhecidas (incluindo RCE no núcleo do framework — julgue pela versão em execução e corrija rápido). Defesas: mantenha segredos no servidor, cuide da fronteira, autorize em cada action, monitore CVEs de dependências por máquina.
Segurança do Ruby on Rails — Strong Parameters, autorização e CVEs de gems
O Rails entrega convenções e padrões seguros (proteção CSRF, Strong Parameters, um ORM) e é sólido quando usado corretamente. Mas os incidentes vêm da operação. Os três grandes: (1) Strong Parameters permissivo demais permitindo Mass Assignment (sobrescrevendo is_admin, etc.), (2) autorização rasa (login = autenticação, mas sem escopo de proprietário), (3) CVEs conhecidos de gems (dependências). Além de SQLi via interpolação de string em where, métodos dinâmicos perigosos (send/constantize) e credentials/secret_key_base vazados. Defesas: aperte o permit, torne a autorização explícita, monitore CVEs de gems.
Segurança do Spring Boot — CVEs de dependências, exposição do Actuator e autorização
O Spring (Spring Boot) é um pilar corporativo. Tipos de incidente: (1) CVEs de dependências conhecidas (uma falha de base amplamente herdada como o Log4Shell — julgue pela versão em execução e corrija rápido), (2) endpoints de gerenciamento/diagnóstico expostos como o Actuator (vazamento de informação / operação), (3) autorização ausente no Spring Security (autenticado mas com checagens de permissão fracas), (4) desserialização insegura. Defesas: monitore CVEs de dependências por máquina e corrija rápido, tranque as superfícies do Actuator/gerenciamento, torne a autorização explícita, não desserialize dados não confiáveis.
Segurança do WordPress — por que é visado e as defesas mínimas
O WordPress tem a maior participação, então é estatisticamente o maior alvo. Os pontos de entrada são menos o núcleo do que vulnerabilidades de plugins/temas, atualizações negligenciadas, administradores fracos/reutilizados e superfícies de administração expostas (wp-admin/xmlrpc/enumeração via REST). Defesas: automatizar atualizações do núcleo+plugins, apagar plugins/temas não usados, senha forte + 2FA para administradores, limitar a exposição da administração e as tentativas de login, detecção de adulteração mais backups offline.