access control
10 artigos com esta tag
O que é o OWASP Top 10 — a lista padrão dos 10 maiores riscos de aplicações web
O OWASP Top 10 é uma lista que a organização sem fins lucrativos OWASP publica a cada poucos anos com os 'riscos mais críticos de aplicações web'. É uma linguagem comum entre desenvolvedores e operadores. A edição atual (2021) é liderada por Controle de Acesso Quebrado, seguida de injeção, configuração incorreta, componentes vulneráveis e desatualizados, falhas de autenticação e mais. Estas são CATEGORIAS de risco, não exploits individuais — use-as como uma lente para auditar o seu próprio app.
O que é o PCI DSS — o padrão de segurança para lidar com dados de cartão de crédito
O PCI DSS (Payment Card Industry Data Security Standard) é o padrão internacional para empresas que armazenam, processam ou transmitem dados de cartão. Definido pelas bandeiras de cartão, ele exige proteção de rede, criptografia dos dados armazenados, controle de acesso de menor privilégio, monitoramento/registro e gestão de vulnerabilidades. Na prática, o movimento mais seguro é não guardar você mesmo os números de cartão — entregue o processamento a um provedor de pagamento em conformidade (tokenização) e reduza o seu escopo.
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 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 Next.js — uma referência de hardening para produção
Os padrões do Next.js são bastante seguros, mas os incidentes acontecem na fronteira servidor/cliente. Esta é uma referência de trabalho: (1) uma lista de verificação de hardening por ordem de prioridade (P0–P2), (2) orientação por área — a fronteira e as variáveis de ambiente (NEXT_PUBLIC_), CVEs de dependências (incluindo RCE no núcleo), autorização em Server Actions / Route Handlers + validação de entrada, SSRF em buscas do lado do servidor, cabeçalhos de segurança/CSP, autenticação/sessão/cookies, limitação de taxa, e (3) uma lista 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.
Segurança do Express (Node.js) — uma referência de hardening para produção
O Express é minimalista — ele quase não protege nada por padrão, então você adiciona as defesas. Esta é uma referência de trabalho: (1) um checklist de hardening priorizado (P0–P2), (2) orientação por área — cabeçalhos de segurança (helmet) + desabilitar x-powered-by, CVEs de dependências npm, validação de entrada e injeção (operador SQL/NoSQL), autenticação e autorização com escopo de dono, limitação de taxa e limites de tamanho, sessões/cookies/CSRF, SSRF, tratamento de erros em produção (sem exposição de stack), NODE_ENV, e (3) um checklist de autoverificação. Apenas defensivo — sem passos de ataque.
Segurança do Ruby on Rails — uma referência de hardening de produção
O Rails entrega convenções e padrões seguros (proteção CSRF, Strong Parameters, um ORM), mas os incidentes de produção vêm da operação. Esta é uma referência de trabalho: (1) um checklist de hardening ordenado por prioridade (P0–P2), (2) orientação por área — segredos e credentials (master key/secret_key_base), config de produção (force_ssl, sem exposição de exceções), CVEs de gems, Strong Parameters/Mass Assignment, autorização (Pundit, escopo de proprietário), injeção e métodos perigosos (interpolação em where/send/constantize), sessões/cookies/CSRF, SSRF/uploads e (3) um checklist de autoverificação. Só defensivo — sem passos de ataque.
Adicionou um login e achou que estava seguro? — autenticação vs autorização
Autenticação = verificar quem é a pessoa; autorização = decidir o que ela pode fazer. São coisas diferentes, e adicionar um login não é autorização. Sem restringir os dados ao dono (user_id), 'logado = vê todos os dados' — o Broken Access Control, o número um do OWASP. Some a isso um scaffold de registro aberto e um estranho pode se cadastrar e entrar. Defesas: restrinja toda consulta ao dono, feche o registro desnecessário, defesa em profundidade, logs de auditoria/acesso antes do incidente, detecte novos cadastros.
O que é IDOR — ver os dados de outra pessoa só trocando um ID
O IDOR permite que um usuário troque ?id=124 por 125 e leia a fatura ou os dados pessoais de outra pessoa — controle de acesso quebrado. A defesa de verdade: no servidor, verificar a cada acesso se o usuário logado tem permissão sobre este objeto. IDs difíceis de adivinhar não são uma correção.