OWASP Top 10: Os 10 Principais Riscos para Aplicações Web e sua Prevenção

Fernando Silva
10 min readFeb 27, 2023
OWASP Top 10:2021

Na área de segurança de aplicações, a OWASP é uma comunidade que cria publicações, abordagens, documentações, ferramentas e tecnologias que podem ser acessadas gratuitamente. Oferece materiais abertos e gratuitos. Basicamente, o OWASP Top 10 Risks é uma lista das dez principais ameaças à segurança de aplicações, criada para informar os usuários sobre os riscos e fraquezas de segurança mais comuns que podem resultar em perda ou comprometimento de dados.

O OWASP mantém sua lista Top 10 desde 2003, atualizando-a a cada dois ou três anos conforme os avanços e mudanças no mercado de AppSec. A importância da lista reside nas informações acionáveis ​​que ela fornece ao servir como uma lista de verificação e um padrão interno de desenvolvimento de aplicações para muitas das maiores organizações do mundo.

Na última atualização, a lista de 2021, o OWASP adicionou três novas categorias, fez quatro alterações na nomenclatura e no escopo e fez algumas consolidações.

OWASP Top 10:2021

1. Broken Access Control (A01:2021)

Anteriormente o número 5 na lista, o Broken Access Control — uma fraqueza que permite que um invasor obtenha acesso a contas de usuário — passou para o número 1 em 2021. O invasor nesse contexto pode acessar como usuário ou administrador do sistema.

Exemplo: Uma aplicação permite que uma chave primária seja alterada e, quando essa chave é alterada para o registro de outro usuário, a conta desse usuário pode ser visualizada ou modificada.

Solução: Uma solução de teste interativo de segurança da aplicação (IAST), pode ajudá-lo a detectar facilmente a falsificação de solicitação entre sites ou o armazenamento inseguro de seus dados confidenciais. Ele também identifica qualquer lógica ruim ou ausente sendo usada para lidar com JSON Web Tokens. O teste de penetração pode servir como um complemento manual para as atividades do IAST, ajudando a detectar controles de acesso não intencionais. Alterações na arquitetura e design podem ser justificadas para criar limites de confiança para acesso a dados. Medidas podem ser tomadas para prevenir, como:

  • Adote uma abordagem de menor privilégio
  • Crie controles de acesso fortes usando mecanismos de autenticação baseados em função
  • Exceto para recursos públicos, nega acesso padrão a funcionalidades
  • Mantenha servidores enxutos desligando serviços desnecessários, excluindo contas inativas e desnecessárias
  • No caso de vários pontos de acesso, desative os que não são necessários
  • A listagem do diretório do servidor deve ser desativada

2. Cryptographic Failures (A02:2021)

Anteriormente na posição número 3 e anteriormente conhecida como exposição de dados confidenciais, essa entrada foi renomeada como falhas criptográficas para retratá-la com precisão como uma causa raiz, em vez de um sintoma. Falhas criptográficas ocorrem quando dados importantes armazenados ou transmitidos (como um número de CPF) são comprometidos.

Exemplo: uma instituição financeira falha em proteger adequadamente seus dados confidenciais e se torna um alvo fácil para fraudes de cartão de crédito e roubo de identidade.

Solução: tanto o teste estático de segurança de aplicações (SAST) quanto a análise de composição de software (SCA) têm verificadores que podem fornecer informações nos níveis de código e componente. No entanto, complementar com o IAST é fundamental para fornecer monitoramento e verificação contínua para garantir que dados confidenciais não vazem durante o teste integrado com outros componentes de software internos e externos. Medidas podem ser tomadas para prevenir, como:

  • Criptografe todos os dados em repouso usando algoritmos, chaves e protocolos de criptografia seguros e robustos
  • Criptografe todos os dados em trânsito usando os protocolos seguros mais recentes, como o TLS
  • Identifique e aplique fortes controles de segurança em todos os dados confidenciais
  • Não colete e armazene dados confidenciais, a menos que seja absolutamente necessário
  • Não armazene em cache dados confidenciais ou em formulários de coleta de dados
  • Desativar preenchimento automático em formulários
  • Minimizar a superfície de ataque
  • Armazene senhas usando funções de hash robustas, adaptáveis ​​e comprovadas

3. Injection (A03:2021)

A injeção desce do número 1 para o número 3, e o cross-site scripting agora é considerado parte dessa categoria. Essencialmente, uma injeção de código ocorre quando dados inválidos são enviados por um invasor a uma aplicação web para fazer com que a aplicação faça algo para o qual não foi projetada.

Exemplo: uma aplicação usa dados não confiáveis ​​ao construir uma chamada SQL vulnerável.

Solução: Incluir ferramentas SAST e IAST em seu pipeline de integração/entrega contínua ( CI/CD ) ajuda a identificar falhas de injeção no nível de código estático e dinamicamente durante o teste de tempo de execução da aplicação. Ferramentas modernas de teste de segurança de aplicativos (AST), podem ajudar a proteger a aplicação durante os vários estágios de teste e verificar uma variedade de ataques de injeção (além de injeções de SQL). Por exemplo, ele pode identificar injeções de NoSQL, injeções de comando, injeções de LDAP, injeções de template e injeções de log. Medidas podem ser tomadas para prevenir, como:

  • A validação de entrada do lado do servidor
  • Use sistemas de detecção de intrusão para identificar comportamentos suspeitos
  • Usar consultas parametrizadas
  • Use LIMIT e outros controles SQL nas consultas, evitando a divulgação em massa de registros
  • Evite caracteres especiais

4. Insecure Design (A04:2021)

O design inseguro é uma nova categoria que se concentra nos riscos relacionados a falhas de design. À medida que as organizações adotam o “shift left”, a modelagem de ameaças, padrões e princípios de design seguros e arquiteturas de referência não são suficientes.

Exemplo: Uma rede de cinemas que permite descontos em reservas de grupos exige um depósito para grupos de mais de 15 pessoas. Os invasores ameaçam modelar esse fluxo para ver se podem reservar centenas de assentos em vários teatros da cadeia, causando assim milhares de dólares em perda de receita.

Solução: o IAST detecta vulnerabilidades e expõe todas as APIs, serviços e chamadas de funções de entrada e saída em aplicações baseados em microsserviços, nuvem e web altamente complexos . Ao fornecer um mapa visual do fluxo de dados e dos endpoints envolvidos, quaisquer pontos fracos no design da aplicação ficam claros, auxiliando nos esforços de teste de penetração e modelagem de ameaças. Medidas podem ser tomadas para prevenir, como:

  • Integre a segurança diretamente nos estágios SDLC e aproveite práticas de segurança robustas desde os estágios iniciais
  • Estabeleça uma biblioteca de padrões de design seguros, componentes, estruturas, etc. que estejam prontos e seguros para uso em novas aplicações
  • Use a modelagem de ameaças para projetar recursos críticos, como controles de acesso, autenticação, lógica de negócios, etc.
  • Com base nas necessidades de exposição e proteção, divida as aplicações em diferentes níveis e encontre casos de uso e uso indevido para cada nível

5. Security Misconfiguration (A05:2021)

A antiga categoria de entidades externas passa a fazer parte desta categoria de risco, que sobe da 6ª posição. Erros de configuração de segurança são deficiências de design ou configuração que resultam de um erro ou falha de configuração.

Exemplo: Uma conta padrão e sua senha original ainda estão habilitadas, tornando o sistema vulnerável a exploits.

Solução: Soluções como o SAST incluem um verificador que identifica a exposição da informação disponível através de uma mensagem de erro. Ferramentas dinâmicas como o IAST podem detectar a divulgação de informações e configurações de cabeçalho HTTP inapropriadas durante o teste de tempo de execução da aplicação. Medidas podem ser tomadas para prevenir, como:

  • Fortaleça a segurança da aplicação usando processos
  • Use modelos pré-configurados (com credenciais diferentes) para configurar desenvolvimento, controle de qualidade e produção de forma idêntica
  • Mantenha uma biblioteca de imagens de contêiner configuradas com segurança
  • Remova recursos e serviços não utilizados e implante uma aplicação com configuração mínima
  • Atualizar e corrigir configurações regularmente
  • Use fluxos de trabalho automatizados para verificar configurações seguras e detectar configurações incorretas em qualquer ambiente. Corrija os problemas identificados instantaneamente.

6. Vulnerable and Outdated Components (A06:2021)

Esta categoria passa do número 9 e se relaciona a componentes que apresentam riscos de segurança conhecidos e potenciais, e não apenas os primeiros. Componentes com vulnerabilidades conhecidas, como CVEs, devem ser identificados e corrigidos, enquanto componentes obsoletos ou maliciosos devem ser avaliados quanto à viabilidade e ao risco que podem apresentar.

Exemplo: devido ao volume de componentes usados ​​no desenvolvimento, uma equipe de desenvolvimento pode não conhecer ou entender todos os componentes usados ​​em sua aplicação, e alguns desses componentes podem estar desatualizados e, portanto, vulneráveis ​​a ataques.

Solução: ferramentas de análise de composição de software (SCA), podem ser usadas juntamente com análise estática e IAST para identificar e detectar componentes desatualizados e inseguros em uma aplicação. IAST e SCA funcionam bem juntos, fornecendo informações sobre como os componentes vulneráveis ​​ou desatualizados estão realmente sendo usados. Medidas podem ser tomadas para prevenir, como:

  • Manter um inventário atualizado de todos os componentes utilizados na aplicação com suas versões
  • Verifique continuamente componentes, bibliotecas, etc. e suas dependências em busca de vulnerabilidades
  • Mantenha todos os componentes atualizados. Se os patches não estiverem disponíveis imediatamente, aplique patches virtuais
  • Remova componentes, recursos e dependências não utilizados, herdados e desatualizados de aplicações
  • Use componentes, software, etc. de fontes oficiais e confiáveis

7. Identification and Authentication Failures (A07:2021)

Anteriormente conhecida como quebra de autenticação, essa entrada desceu do número 2 e agora inclui CWEs relacionados a falhas de identificação. Especificamente, funções relacionadas à autenticação e gerenciamento de sessão, quando implementadas incorretamente, permitem que invasores comprometam senhas, palavras-chave e sessões, o que pode levar ao roubo da identidade do usuário e muito mais.

Exemplo: Uma aplicação web permite o uso de senhas fracas ou fáceis de adivinhar (exemplo, “senha1”).

Solução: a autenticação multifator pode ajudar a reduzir o risco de contas comprometidas, e a análise estática automatizada é muito útil para encontrar essas falhas, enquanto a análise estática manual pode adicionar força ao avaliar esquemas de autenticação personalizados. O IAST pode detectar senhas e credenciais codificadas, bem como autenticação imprópria ou falta de etapas críticas na autenticação. Medidas podem ser tomadas para prevenir, como:

  • A autenticação multifator
  • Não use credenciais padrão, especialmente para privilégios de administrador
  • Implemente uma política de senha forte
  • Implante um gerenciador de sessões seguro que gera IDs de sessão com tempo limitado
  • Monitore as tentativas de login com falha e defina limites e atrasos nas mesmas
  • Fortaleça o registro, a recuperação de credenciais e outros processos relacionados à autenticação

8. Software and Data Integrity Failures (A08:2021)

Esta é uma nova categoria que se concentra em atualizações de software, dados críticos e pipelines de CI/CD usados ​​sem verificar a integridade. Também agora incluída nesta entrada, a desserialização insegura é uma falha de desserialização que permite que um invasor execute código remotamente no sistema.

Exemplo: um aplicativo desserializa objetos hostis fornecidos pelo invasor, abrindo-se à vulnerabilidade.

Solução: as ferramentas de segurança da aplicação ajudam a detectar falhas de desserialização e o teste de penetração pode validar o problema. O IAST também pode verificar a desserialização insegura e ajudar a detectar redirecionamentos inseguros ou qualquer adulteração de algoritmos de acesso de token. Medidas podem ser tomadas para prevenir, como:

  • Garantir a legitimidade do software/dados/programas e sua fonte por meio de assinatura digital ou medidas semelhantes
  • Garanta a integridade do pipeline de CI/CD por meio de controles de acesso fortes, configuração adequada e segregação adequada
  • Revise continuamente o código e as configurações para modificações
  • Certifique-se de que as bibliotecas e dependências usem repositórios confiáveis. Você pode hospedar um repositório interno, aprovado e conhecido se seu perfil de risco for maior
  • Dados serializados não criptografados não devem ser entregues a clientes não confiáveis, portanto, incorpore verificações de integridade

9. Security Logging and Monitoring Failures (A09:2021)

Anteriormente conhecido como log e monitoramento insuficientes, essa entrada passou do número 10 e foi expandida para incluir mais tipos de falhas. O registro e o monitoramento são atividades que devem ser executadas com frequência em uma aplivação — deixar de fazê-lo deixa a aplicação vulnerável a atividades comprometedoras mais graves.

Exemplo: Eventos que podem ser auditados, como logins, logins com falha e outras atividades importantes, não são registrados, levando a uma aplicação vulnerável.

Solução: Depois de realizar o teste de penetração, os desenvolvedores podem estudar os logs de teste para identificar possíveis deficiências e vulnerabilidades. SAST e IAST podem ajudar a identificar exceções de segurança não registradas. Medidas podem ser tomadas para prevenir, como:

  • Use software de registro e auditoria prontamente disponível que ajuda na detecção instantânea de atividades suspeitas
  • Certifique-se de que os logs sejam contextuais e disponíveis em formatos compatíveis para análise forense aprofundada
  • Aplicar controles de segurança que ajudam a evitar a adulteração de dados de log

10. Server-Side Request Forgery (A10:2021)

Uma nova categoria, server-side request forgery (SSRF) pode acontecer quando uma aplicação web busca um recurso remoto sem validar a URL fornecida pelo usuário. Isso permite que um invasor faça a aplicação enviar uma requisição criada para um destino inesperado, mesmo quando o sistema estiver protegido por um firewall, VPN ou lista de controle de acesso à rede. A gravidade e a incidência de ataques SSRF estão aumentando devido aos serviços em nuvem e ao aumento da complexidade das arquiteturas.

Exemplo: se uma arquitetura de rede não for segmentada, os invasores podem usar os resultados da conexão ou o tempo decorrido para conectar ou rejeitar conexões de carga SSRF para mapear redes internas e determinar se as portas estão abertas ou fechadas em servidores internos.

Solução: Uma ferramenta AST que pode rastrear, monitorar e detectar SSRF sem a necessidade de varredura e triagem adicionais. Medidas podem ser tomadas para prevenir, como:

  • Aplicar validação e sanitização de entrada do usuário
  • As funcionalidades de acesso remoto a recursos, se houver, devem ser isoladas
  • Bloqueie tráfego de entrada indesejado usando políticas de firewall de negação por padrão
  • Crie uma lista de permissões positiva para porta, destino e esquema de URL
  • Não permitir redirecionamentos HTTP

Para concluir, os 10 principais riscos da OWASP facilita aos usuários a compreensão das ameaças de segurança mais comuns e fornece regras práticas quando se trata de manter as aplicações protegidas contra vulnerabilidades conhecidas. Portanto, é altamente recomendável adotar o OWASP Top 10 Risks para reduzir ou mitigar os riscos de segurança associados as aplicações.

Referências:
https://owasp.org/www-project-top-ten/

--

--

Fernando Silva

Application Security Engineer | OWASP Chapter Leader | AppSec | MSc CyberSecurity | Systems Development Analyst