A06:2025 Design Inseguro

Contexto

O Design Inseguro caiu duas posições, passando de #4 para #6 no ranking, sendo ultrapassado por A02:2025-Configuração Insegura e A03:2025-Falhas na Cadeia de Suprimentos de Software. Esta categoria foi introduzida em 2021 e temos observado melhorias notáveis na indústria em relação à modelagem de ameaças e uma maior ênfase em design seguro. Esta categoria foca em riscos relacionados a falhas de design e arquitetura, com um apelo para o maior uso de modelagem de ameaças, padrões de design seguro (secure design patterns) e arquiteturas de referência. Isso inclui falhas na lógica de negócio de uma aplicação, por exemplo, a falta de definição de mudanças de estado indesejadas ou inesperadas dentro de uma aplicação. Como comunidade, precisamos ir além do "shift-left" no espaço da codificação para atividades pré-código, como a escrita de requisitos e o design da aplicação, que são críticos para os princípios de Secure by Design (veja, por exemplo, Estabelecendo um Programa de AppSec Moderno: Fase de Planejamento e Design). Enumerações de Fraquezas Comuns (CWEs) notáveis incluem CWE-256: Armazenamento Não Protegido de Credenciais, CWE-269 Gerenciamento Inadequado de Privilégios, CWE-434 Upload Irrestrito de Arquivo com Tipo Perigoso, CWE-501: Violação de Limite de Confiança e CWE-522: Credenciais Protegidas de Forma Insuficiente.

Tabela de pontuação

CWEs Mapeadas	Taxa Máx. de Incidência	Taxa Méd. de Incidência	Cobertura Máxima	Cobertura Média	Exploit Ponderado Médio	Impacto Ponderado Médio	Total de Ocorrências	Total de CVEs
39	22,18%	1,86%	88,76%	35,18%	6,96	4,05	729.882	7.647

Descrição

O design inseguro é uma categoria ampla que representa diferentes fraquezas, expressas como "design de controle ausente ou ineficaz". O design inseguro não é a origem de todas as outras categorias de risco do Top Ten. Observe que existe uma diferença entre design inseguro e implementação insegura. Diferenciamos falhas de design de defeitos de implementação por um motivo: eles possuem causas raízes diferentes, ocorrem em momentos diferentes do processo de desenvolvimento e possuem remediações distintas. Um design seguro ainda pode apresentar defeitos de implementação que levam a vulnerabilidades passíveis de exploração. Já um design inseguro não pode ser corrigido por uma implementação perfeita, uma vez que os controles de segurança necessários para defender contra ataques específicos nunca foram criados. Um dos fatores que contribui para o design inseguro é a falta de perfil de risco de negócio (business risk profiling) inerente ao software ou sistema sendo desenvolvido e, consequentemente, a falha em determinar qual nível de design de segurança é necessário.

Três partes fundamentais para ter um design seguro são:

Coleta de Requisitos e Gerenciamento de Recursos
Criação de um Design Seguro
Manutenção de um Ciclo de Vida de Desenvolvimento Seguro (SDLC)

Requisitos e Gerenciamento de Recursos

Colete e negocie os requisitos de negócio para uma aplicação com as partes interessadas, incluindo os requisitos de proteção relativos à confidencialidade, integridade, disponibilidade e autenticidade de todos os ativos de dados e a lógica de negócio esperada. Leve em conta o quão exposta sua aplicação estará e se você precisa de segregação de instâncias (tenants) — além daquelas necessárias para o controle de acesso. Compile os requisitos técnicos, incluindo requisitos de segurança funcionais e não funcionais. Planeje e negocie o orçamento cobrindo todo o design, construção, testes e operação, incluindo atividades de segurança.

Design Seguro

O design seguro é uma cultura e metodologia que avalia constantemente as ameaças e garante que o código seja projetado e testado de forma robusta para prevenir métodos de ataque conhecidos. A modelagem de ameaças deve ser integrada às sessões de refinamento (ou atividades similares); busque por mudanças nos fluxos de dados e no controle de acesso ou outros controles de segurança. No desenvolvimento da user story, determine o fluxo correto e os estados de falha, garantindo que sejam bem compreendidos e acordados pelas partes responsáveis e impactadas. Analise suposições e condições para fluxos esperados e de falha para garantir que permaneçam precisos e desejáveis. Determine como validar as suposições e impor as condições necessárias para comportamentos adequados. Garanta que os resultados sejam documentados na user story. Aprenda com os erros e ofereça incentivos positivos para promover melhorias. O design seguro não é um acessório nem uma ferramenta que você possa adicionar ao software.

Ciclo de Vida de Desenvolvimento Seguro

Software seguro exige um ciclo de vida de desenvolvimento seguro, um padrão de design seguro, uma metodologia de "estrada pavimentada" (paved road), uma biblioteca de componentes seguros, ferramentas apropriadas, modelagem de ameaças e pós-mortems de incidentes que sejam usados para melhorar o processo. Entre em contato com seus especialistas em segurança no início de um projeto de software, ao longo de todo o projeto e para a manutenção contínua do software. Considere utilizar o OWASP Software Assurance Maturity Model (SAMM) para ajudar a estruturar seus esforços de desenvolvimento de software seguro.

Frequentemente, a autorresponsabilidade dos desenvolvedores é subestimada. Promova uma cultura de conscientização, responsabilidade e mitigação proativa de riscos. Trocas regulares sobre segurança (ex: durante sessões de modelagem de ameaças) podem gerar uma mentalidade para incluir a segurança em todas as decisões importantes de design.

Como prevenir

Estabeleça e utilize um ciclo de vida de desenvolvimento seguro com profissionais de AppSec para ajudar a avaliar e projetar controles relacionados à segurança e privacidade.
Estabeleça e utilize uma biblioteca de padrões de design seguro ou componentes de "estrada pavimentada" (paved road).
Utilize a modelagem de ameaças para partes críticas da aplicação, como autenticação, controle de acesso, lógica de negócio e fluxos principais.
Utilize a modelagem de ameaças como uma ferramenta educacional para gerar uma mentalidade de segurança.
Integre linguagem e controles de segurança nas user stories.
Integre verificações de plausibilidade em cada camada da sua aplicação (do frontend ao backend).
Escreva testes de unidade e integração para validar que todos os fluxos críticos são resistentes ao modelo de ameaças. Compile casos de uso (use-cases) e casos de abuso (misuse-cases) para cada camada da sua aplicação.
Segregue as camadas do sistema e da rede, dependendo da exposição e das necessidades de proteção.
Segregue instâncias (tenants) de forma robusta por design em todas as camadas.

Exemplos de cenários de ataque

Cenário #1: Um fluxo de recuperação de credenciais pode incluir "perguntas e respostas", o que é proibido pelo NIST 800-63b, pelo OWASP ASVS e pelo OWASP Top 10. Perguntas e respostas não podem ser confiáveis como prova de identidade, pois mais de uma pessoa pode saber as respostas. Tal funcionalidade deve ser removida e substituída por um design mais seguro.

Cenário #2: Uma rede de cinemas permite descontos para reservas em grupo e possui um máximo de quinze participantes antes de exigir um depósito. Atacantes poderiam modelar as ameaças deste fluxo e testar se conseguem encontrar um vetor de ataque na lógica de negócio da aplicação, por exemplo, reservando seiscentos assentos em todos os cinemas de uma só vez em poucas requisições, causando uma perda massiva de receita.

Cenário #3: O site de e-commerce de uma rede varejista não possui proteção contra bots operados por cambistas (scalpers) que compram placas de vídeo de alto desempenho para revender em sites de leilão. Isso gera uma publicidade terrível para os fabricantes de placas de vídeo e para os proprietários da rede varejista, além de um rancor duradouro com os entusiastas que não conseguem obter essas placas por preço algum. Um design anti-bot cuidadoso e regras de lógica de domínio, como identificar compras feitas em poucos segundos após a disponibilidade, poderiam identificar compras inautênticas e rejeitar tais transações.