Introdução
O CWE-657 é uma nova categoria que tomou posse no OWASP TOP 10 e foca principalmente nos riscos relacioandos a falha de design e arquitetura, com um apelo maior para a modelagem de ameaças, padrões de design de segurança e referência de arquiteturas seguras. os (CWE-209) Information Exposure Through an Error Message, (CWE-256) Plaintext Storage of a Password, (CWE-501) Trust Boundary Violation, (CWE-522) Insufficiently Protected Credentials são vulnerabilidades facilmente identificaveis que podem fazer parte do CWE-657.
Descrição
Violações de princípios de design de segurança é uma categoria que aborda diferentes aspectos de vulnerabilidades. Entretanto, um design não-seguro não é a fonte para o Top 10 de categorias da OWASP. Existe uma diferença entre um design não-seguro e uma implementação não-segura. Nós diferenciamos falhas de design e falhas de implementação por um motivo: eles tem diferentes raízes e consequências. Um design seguro ainda pode levar a vulnerabilidades em uma implementação não segura, que podem ser exploradas a partir de exploits. Um design não-seguro pode ser melhorado por uma implementação perfeitamente segura, criando todos os controles de segurança possíveis para todos os tipos de ataques possíveis. Um dos fatores que contribui para um design não-seguro é a falta de um perfil de risco empresarial para os desenvolvedores de software, e, portanto, as falhas começam a surgir no nível de design de segurança.
Em tese, a falta de um perfil e de conhecimento no ambiente de desenvolvimento de um software sobre os riscos de um design não-seguro pode levar, acaba por criar um ambiente de desenvolvimento de software fora das limitações do desenvolvimento de um software pautado em um design de segurança decente e bem estruturado.
Como prevenir
- Estabelecer e utilizar desenvolvimento de ciclo de vida de aplicação pautados com o auxílio de profissionais em AppSec em design de segurança e controle de privacidade
- Estabelecer e utilizar bibliotecas de padrões de design ou utilizar funções já seguras e prontas para uso
- Utilizar a modelagem de ameaças para autenticações críticas, controles de acesso, lógica digital e etc
- Integrar controles de segurança nas “histórias de usuário”
- Integrar testes em todas as camadas de sua aplicação (do front-end até o back-end)
- Limitar os recursos que podem ser utilizados pelo usuário
- Segregar, de forma robusta, todos os clientes em todos as camadas
- Segregar todas as camadas do sistema e todas as camadas da rede dependendo da exposição e proteção que elas precisam
- Escrever um modelo e integração de testes para validar se todas as possíveis falhas críticas são vulneráveis a modelos de ameaça.
Exemplos de casos de ataque
Cenário #1: Recuperação de senha por meio de um questionário de “Perguntas e respostas”, que está proibido pelo NIST 800-63b e o OWASP ASVS. Perguntas e respostas não podem ser confiáveis como evidência de identidade, já que mais de uma pessoa pode saber as respostas. Por esse motivo, a recuperação de senha por meio de um questionário de “Perguntas e respostas” é proibida. Todo código que contém esse design deve ser substituído por um design mais seguro e eficiente.
Cenário #2: Uma rede de cinema permite reservar um máximo de 15 cadeiras antes de requisitar algum deposito. Um hacker pode ameaçar esse sistema ao reservar centenas de acentos no cinema em alguns requests, causando uma massiva perda de dinheiro.
Cenário #3: Um site de e-commerce não contém proteção contra bots que compram seus produtos para revender sem sites de marketplace por um preço maior. Isso cria uma péssima publicidade para o site, já que os seus clientes não podem comprar seus produtos a qualquer preço e estão sujeitos a comprar pelo preço nos marketplaces. Um design anti-bots e regras de uso do domínio, como em que identifica compras que foram feitas após alguns segundos depois da liberação, podem identificar bots e negar as transações.