OWASP Top 10: vulnerabilidades, exemplos e controles de proteção

Introdução

O OWASP Top 10:2021 organiza riscos relevantes de aplicações web em dez categorias de conscientização. Ele cria vocabulário comum, mas não é uma especificação completa, um checklist de conformidade ou a prova de que uma aplicação está segura.

A Aula 01 aprofundou A01 — Broken Access Control e A02 — Cryptographic Failures. Aqui, o foco está de A03 a A10, nas práticas de verificação e no raciocínio necessário para interpretar achados.

Visão geral do OWASP Top 10:2021

Para revisar A01 e A02, consulte Fundamentos de Segurança Cibernética.

A03 — Injection

Injection ocorre quando dados não confiáveis alteram a estrutura ou o significado de uma instrução interpretada. SQL Injection afeta comandos de banco de dados; OS Command Injection atinge comandos do sistema operacional.

Os controles têm responsabilidades diferentes:

• Validação verifica formato, faixa, tamanho e significado esperado.
• Parametrização separa dados da estrutura de uma consulta ou comando.
• Autorização decide se a identidade pode executar a ação no recurso.

Prepared statements são essenciais contra SQL Injection clássica, mas não tornam uma consulta autorizada. Uma consulta parametrizada ainda pode devolver o pedido de outro cliente se o filtro de propriedade estiver ausente.

const order = await database.query(
  "SELECT id, total FROM orders WHERE id = ? AND customer_id = ?",
  [request.params.id, request.user.id]
);

O exemplo combina parametrização com uma condição de propriedade. O modelo de autorização real pode exigir políticas mais ricas, mas a distinção permanece: dados não viram SQL, e o usuário não recebe acesso apenas por conhecer um identificador.

Para comandos do sistema, prefira APIs que não iniciem um shell e forneça argumentos estruturados. Se um processo externo for inevitável, aplique allowlist de operações, menor privilégio, timeout e observabilidade.

A04 — Insecure Design e abuso de regras de negócio

Insecure Design aparece quando o próprio modelo permite um resultado inseguro. O código pode executar exatamente o que foi especificado e, ainda assim, o sistema aceitar uma sequência que viola o negócio.

Considere a compra de ingressos de cinema. A interface calcula meia-entrada, horário, assento e preço final. Se o servidor aceitar o total enviado pelo cliente, uma requisição tecnicamente válida pode registrar um valor incompatível com as regras.

O mesmo vale para fluxos financeiros e cadastrais. Formato numérico válido não comprova limite disponível; documento bem formatado não comprova elegibilidade; etapa concluída na interface não comprova que o servidor validou a transição.

Threat modeling, casos de abuso e testes de regras complementam scanners. Um Web Application Firewall (WAF) pode bloquear padrões conhecidos, mas não sabe por que um ingresso deveria custar determinado valor.

A05 — Security Misconfiguration

Hardening reduz a superfície de ataque por meio de um baseline conhecido e verificável. Isso inclui desativar serviços e contas desnecessárias, remover exemplos, restringir permissões, configurar cabeçalhos e impedir que depuração fique ativa em produção.

Configurações padrão são um ponto de partida, não uma decisão de segurança. Contas de demonstração, páginas administrativas expostas e armazenamento público podem permanecer acessíveis quando ninguém assume explicitamente sua configuração.

Mensagens de erro excessivas também ampliam risco. Stack traces, nomes de tabelas, caminhos internos e versões de componentes ajudam diagnóstico interno, mas não deveriam ser enviados ao cliente. A resposta pública usa um erro estável e um identificador de correlação; os detalhes permanecem em logs protegidos.

A06 — Componentes vulneráveis e desatualizados

Uma Common Vulnerabilities and Exposures (CVE) identifica publicamente uma vulnerabilidade específica. Saber que uma CVE existe não determina sozinho a prioridade: é preciso confirmar versão afetada, uso real, exposição, controles compensatórios e impacto.

O time precisa manter inventário de dependências diretas, transitivas, imagens, runtimes e ferramentas de build. Uma Software Bill of Materials (SBOM) registra componentes e relações de forma estruturada, apoiando investigação e resposta.

Software Composition Analysis (SCA) compara componentes com fontes de vulnerabilidades e políticas. Ela acelera descoberta, mas pode produzir falsos positivos, desconhecer se o código vulnerável é alcançável ou falhar diante de inventário incompleto.

O tratamento inclui atualização, substituição, isolamento, mitigação temporária ou aceitação formal. Dependência “sem CVE conhecida” não é sinônimo de dependência segura.

A08 — Integridade e cadeia de suprimentos

A cadeia de suprimentos inclui repositórios, dependências, registries, ferramentas, pipelines, artefatos e mecanismos de atualização. O caso SolarWinds é uma referência de comprometimento de supply chain: software distribuído por um canal confiado carregou uma alteração maliciosa para organizações clientes.

A lição arquitetural não é “nunca usar terceiros”. É reduzir confiança implícita e controlar proveniência, acesso ao pipeline, revisão, segregação de funções, construção reproduzível quando viável e resposta a comprometimento.

Assinar um artefato vincula identidade e integridade conforme a política de chaves adotada. Validar assinatura, origem, versão e política antes do deploy é tão importante quanto produzir a assinatura.

A07 — Identificação e autenticação

Falhas de identificação e autenticação incluem sessões mal geridas, recuperação de conta fraca, credenciais expostas e tokens previsíveis ou com ciclo de vida inadequado.

Enumeração ocorre quando resposta, tempo ou comportamento revela quais usuários ou recursos existem. Respostas externas consistentes reduzem esse sinal, enquanto logs internos preservam contexto suficiente para investigação.

Tokens precisam de entropia adequada, prazo, escopo, armazenamento protegido, revogação e proteção em logs e URLs. Autenticação multifator reduz determinados riscos, mas não corrige autorização ausente nem sessão exposta.

A09 — Logging e monitoramento

Logging útil registra eventos relevantes com campos consistentes. Para uma ação sensível, o time pode precisar de identidade, ação, recurso, resultado, identificador de correlação e contexto de negócio estritamente necessário.

A ausência de alertas transforma evento registrado em ruído armazenado. Correlação permite observar uma sequência: enumeração de usuários, várias falhas, autenticação bem-sucedida e alteração privilegiada em pouco tempo.

Um Security Information and Event Management (SIEM) apoia centralização, pesquisa, correlação e alertas. Ele não cria contexto ausente nem garante resposta. Regras precisam ser testadas; responsáveis, severidade, playbooks e prazos precisam estar definidos.

A10 — Server-Side Request Forgery

Server-Side Request Forgery (SSRF) ocorre quando o servidor realiza uma requisição para um destino influenciado pelo cliente sem restrições suficientes.

O servidor pode alcançar portas e serviços internos que não estão expostos à internet. Esquemas inesperados, como file://, podem acessar recursos locais conforme a biblioteca e a configuração. Em ambientes de nuvem, o endereço de link local 169.254.169.254 é associado a serviços de metadata e exige proteção específica.

Depois de alcançar um recurso interno, a requisição pode servir de pivot para novas capacidades. A resposta pode vazar dados, mas SSRF cega também importa: efeitos e diferenças de tempo podem revelar comportamento.

Controles incluem allowlist de destinos, esquemas e portas; parser de URL consistente; resolução e validação de endereços; bloqueio de redirecionamentos; segmentação; proteção do serviço de metadata; e egress control, que limita saídas de rede.

Blocklists são frágeis diante de representações alternativas, resolução de nomes e redirecionamentos. Quando o domínio de destino é conhecido, allowlist é preferível. Quando acesso aberto é requisito, isolamento e controle de rede tornam-se ainda mais importantes.

Ferramentas e práticas de verificação

Nenhuma ferramenta observa todos os tipos de falha. A cobertura nasce da combinação de técnicas, contexto e revisão humana.

Falsos positivos consomem tempo; falsos negativos criam confiança indevida. Resultados precisam ser triados, reproduzidos com segurança, relacionados a ativos e priorizados por risco.

Matriz de categorias e controles

Referências

• OWASP Top 10:2021 — lista e finalidade das dez categorias.
• OWASP SSRF Prevention Cheat Sheet — controles de aplicação e rede para requisições de saída.
• OWASP API Security Top 10:2023 — riscos específicos de interfaces de programação de aplicações.
• OWASP SAMM — modelo de maturidade para segurança no ciclo de software.
• OWASP ZAP — projeto oficial do scanner e proxy de aplicações web.
• CISA — SolarWinds and Active Directory/M365 Compromise — orientação oficial sobre o comprometimento de supply chain.
• MITRE CWE — vocabulário de fraquezas de software e hardware.

Conclusão

O OWASP Top 10:2021 ajuda a organizar conversas, mas a proteção nasce de decisões específicas. Validação, parametrização, autorização e regras de negócio não são intercambiáveis. WAF, SAST, DAST e SCA ampliam cobertura, mas não corrigem automaticamente o sistema.

Aplicações seguras conhecem seus componentes, verificam artefatos, restringem saídas, produzem eventos úteis e mantêm pessoas capazes de interpretar sinais e responder.