design
4 artigos com esta tag
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.
Desserialização insegura: o risco de deixar dados externos escolherem o tipo do objeto, e como evitar
O perigo da desserialização não é que cheguem valores ruins; é que alguns formatos deixam os dados externos decidirem que tipo de objeto construir. Por isso o dano não para em dados corrompidos — a OWASP lista negação de serviço, contorno de controle de acesso e execução remota de código. Duas defesas: trocar para um formato só de dados, em que nada escolhe tipos por você, e assinar as mensagens serializadas para que as não assinadas nunca sejam restauradas. E alguns mecanismos não podem ser tornados seguros por configuração; a única correção é não usá-los.
Falhas de design na redefinição de senha: 5 formas de tomar contas mesmo com login forte, e como corrigir
Um fluxo de redefinição é um mecanismo para deixar alguém que não sabe a senha definir uma nova — o que o torna um caminho de autenticação por si só. Fortaleça o login quanto quiser: se a redefinição for fraca, ela é a sua força real de autenticação. Cinco formas de falha: tokens adivinháveis, tokens que nunca expiram, links que continuam vivos numa caixa de e-mail, links cujo destino pode ser definido de fora (cabeçalho Host) e respostas que revelam se uma conta existe. O passo-chave na implementação é separar o que a orientação exige dos números que ela deixa para você.
Limitação de taxa e controle de abuso: como projetar limites que barram força bruta e custos descontrolados
A limitação de taxa costuma falhar não porque o limite era frouxo demais, mas porque a pergunta errada foi feita. Três perguntas: quem você conta (o IP pode ser forjado e é compartilhado por usuários reais, então a identidade vem primeiro), o que você conta (só requisições deixam passar operações caras isoladas — custo, tamanho, número de registros) e o que acontece no teto (bloqueio rígido é uma negação de serviço contra usuários legítimos). O NIST limita as falhas consecutivas a 100 e pede atrasos e CAPTCHA em vez de trancar as pessoas do lado de fora; o OWASP inclui limites de gasto com terceiros, o controle final contra dano financeiro.