O que é o OWASP Top 10?

O Open Web Application Security Project (OWASP) é uma comunidade de segurança de aplicativos de código aberto com o objetivo de melhorar a segurança do software. O OWASP Top 10 é uma diretriz padrão do setor que lista os riscos mais críticos de segurança de aplicativos para ajudar os desenvolvedores a proteger melhor os aplicativos que projetam e implantam.

Como os riscos de segurança estão em constante evolução, a lista OWASP Top 10 é revisada periodicamente para refletir essas mudanças. Na versão mais recente da OWASP Top 10, lançada em 2021, alguns tipos de vulnerabilidades que não representam mais uma ameaça séria foram substituídos por outros que provavelmente representarão um risco significativo.

Embora o OWASP Top 10 seja um ótimo lugar para começar a proteger os aplicativos, ele certamente não deve ser considerado como um objetivo final, pois algumas das vulnerabilidades mais citadas não entraram no OWASP Top 10 2021. Para se protegerem contra os pontos fracos do software, os defensores precisam examinar de forma mais ampla toda a pilha de tecnologia da informação. Isso significa que os profissionais de segurança de TI precisam se concentrar em todo o ecossistema de software e olhar além das fontes "tradicionais" de vulnerabilidades.

Quais são as categorias do OWASP Top 10 (2021)?

A1: Injeção

As falhas de injeção podem ser introduzidas sempre que uma fonte de dados não confiável é enviada a um intérprete. Os exemplos são frequentemente encontrados em consultas a bancos de dados dinâmicos SQL, LDAP, XPath ou NoSQL com entrada fornecida pelo usuário. Os invasores injetam código na entrada do usuário, induzindo o interpretador de consultas a executar comandos maliciosos.

O que torna um aplicativo vulnerável a falhas de injeção?

• Os dados fornecidos pelo usuário não estão sendo suficientemente validados.
• As consultas dinâmicas são executadas sem sanitização de entrada suficiente.
• Dados hostis usados nos sistemas para comportamento malicioso.

Qual é o impacto das falhas de injeção?

• Comprometimento do aplicativo ou do host subjacente.
• Exposição de dados confidenciais.
• Perda de produtividade, reputação ou receita.

Como o site Fortify pode ajudar com as falhas de injeção?

• Se você for um desenvolvedor: Fortify detecta falhas de injeção e fornece conselhos de correção específicos para cada tipo.
• Se você trabalha com controle de qualidade ou operações: Fortify valida o código em tempo de execução para controles de atenuação.
• Se você estiver em Operações: Fortify fornece registro em tempo de execução e proteção para tentativas de injeção em Java e .NET.

---

A2: Autenticação interrompida

A autenticação quebrada pode ser introduzida ao gerenciar dados de identidade ou de sessão em aplicativos com estado. Exemplos são frequentemente encontrados quando o registro, a recuperação de credenciais e os caminhos de API são vulneráveis a tokens de sessão não expirados, força bruta ou enumeração de contas. Os invasores assumem a identidade de usuários legítimos, assumindo o controle de contas e comprometendo dados, processos ou sistemas.

O que torna um aplicativo vulnerável à quebra de autenticação?

• Expõe, não invalida adequadamente ou falha na rotação de IDs de sessão.
• Não alinha as políticas de senha com padrões como o NIST 800-63B.
• Não possui autenticação de dois fatores (2FA) ou permite ataques automatizados.

Qual é o impacto da autenticação interrompida?

• Roubo de identidade do usuário.
• Perda da confiança do usuário.
• Comprometimento de dados confidenciais.

Como o site Fortify pode ajudar?

• Se você for desenvolvedor: Fortify detecta e recomenda a correção de problemas de autenticação interrompida.
• Se você estiver em QA ou Operações: Fortify valida a autenticação e a segurança do gerenciamento de sessões de forma dinâmica.
• Se você estiver em Operações: Fortify instrumenta o monitoramento de tempo de execução para eventos de aplicativos Java e .NET.

---

A3: Exposição de dados confidenciais

Problemas de exposição a dados confidenciais podem ser introduzidos quando os aplicativos acessam dados não criptografados, principalmente informações de identificação pessoal (PII) e outros tipos de dados regulamentados. Os exemplos são frequentemente encontrados quando cifras criptográficas fracas são usadas em aplicativos legados, protocolos de transporte seguro são implementados incorretamente ou a segurança centrada em dados não está em uso. Os invasores obtêm acesso a dados confidenciais do usuário que lhes dão controle na vida real.

O que torna um aplicativo vulnerável à exposição de dados confidenciais?

• Transmissão de dados em texto claro por meio de protocolos como HTTP, SMTP e FTP.
• Dados confidenciais sendo armazenados, transmitidos ou usados desnecessariamente em texto claro.
• Uso de algoritmos criptográficos antigos, fracos ou não baseados em padrões.

Qual é o impacto da exposição de dados confidenciais?

• Comprometimento de dados regulamentados (por exemplo, HIPAA ou GDPR), resultando em multas.
• Sequestro de identidade, resultando em custos para limpar ou monitorar dados.
• Status de não conformidade com as leis e normas de privacidade.

Como o site Fortify pode ajudar na exposição de dados confidenciais?

• Se você for um desenvolvedor: Fortify identifica a exposição de dados confidenciais e automatiza a auditoria de problemas.
• Se você trabalha com controle de qualidade ou operações: Fortify remove descobertas atenuadas fora do contexto do aplicativo com modelos.
• Se estiver na área de Operações: Fortify registra e protege instrumentos para aplicativos em Java e .NET.

---

A4: Entidades externas XML

Os problemas de entidade externa XML podem ser introduzidos quando uma entrada XML que contém uma referência a uma entidade externa é processada por um analisador mal configurado. Os exemplos são frequentemente encontrados em aplicativos que analisam a entrada XML de fontes não confiáveis, quando as DTDs (Document Type Definitions, definições de tipos de documentos) estão ativadas ou que usam estruturas não corrigidas, como o SOAP 1.0. O XML está em toda parte, desde arquivos SVG e de imagem até protocolos de rede e formatos de documentos, como PDF e RSS. Os invasores fazem referência a entidades externas na entrada XML, o que resulta em processadores explorados para extrair dados, executar códigos remotamente ou afetar os serviços de rede.

O que torna um aplicativo vulnerável a entidades externas XML?

• O aplicativo analisa documentos XML e os processadores têm DTDs ativados.
• Usar SAML para SSO, SOAP anterior à v1.2 ou .NET Framework anterior à v2.0.
• O analisador aceita fontes não confiáveis ou insere dados XML não confiáveis.

Qual é o impacto das entidades externas XML?

• Roubo de dados confidenciais.
• Carregamento de URL controlado por invasor.
• Ataques de negação de serviço (DoS).

Como o site Fortify pode ajudar com entidades externas XML?

• Se você for um desenvolvedor: Fortify detecta analisadores XML vulneráveis e recomenda fatores de atenuação.
• Se você trabalha com controle de qualidade ou operações: Fortify verifica automaticamente se há analisadores XML vulneráveis e valida cargas úteis de exploração.
• Se você trabalha com operações: Fortify oferece registro em tempo de execução e proteção para problemas em aplicativos Java e .NET.

---

A5: Controle de acesso quebrado

Problemas de controle de acesso podem ser introduzidos quando o código e as restrições ambientais se sobrepõem de forma incompleta ou são definidos em vários locais para uma funcionalidade semelhante. Exemplos são encontrados com frequência quando a segurança por obscuridade é quebrada por meio de navegação forçada em páginas restritas ou quando o aplicativo define métodos complexos para controle de acesso de várias maneiras e locais. Os invasores podem comprometer os limites de acesso para roubar dados confidenciais ou interromper as operações.

O que torna um aplicativo vulnerável a falhas no controle de acesso?

• Capacidade de atuar como usuário sem login ou como administrador quando conectado como usuário.
• Manipulação de metadados ou tokens para privilégios não autorizados ou elevados.
• Lógica de controle de acesso bizantina, não aplicada ou dispersa.

Qual é o impacto de um controle de acesso interrompido?

• Divulgação de informações não autorizadas ou comprometimento de dados confidenciais.
• Modificação ou destruição de dados.
• Controle da administração do site ou dos usuários.

Como o site Fortify pode ajudar com o controle de acesso interrompido?

• Se você for um desenvolvedor: Fortify automatiza a auditoria e permite a criação de modelos para remover problemas atenuados em outros lugares.
• Se você trabalha com controle de qualidade e operações: os agentes do Fortify detectam superfícies de ataque ocultas e sistemas de controle de acesso quebrados.
• Se você estiver em Operações: Fortify instrumenta o registro de controle de acesso em tempo de execução para aplicativos Java e .NET.

---

A6: Configuração incorreta da segurança

As falhas de configuração incorreta da segurança podem ser introduzidas durante a configuração do aplicativo ou de seu ambiente subjacente. A configuração incorreta pode ocorrer em qualquer nível de uma pilha de aplicativos, desde serviços de rede e servidores de aplicativos até contêineres e armazenamento. Os exemplos são frequentemente encontrados em contas e configurações padrão, mensagens de erro com "vazamento" ou estruturas e serviços sem patches. Os invasores podem obter informações de implementação e acesso a dados privilegiados para interromper as operações.

O que torna um aplicativo vulnerável à configuração incorreta da segurança?

• Portas e contas padrão ativadas desnecessariamente ou senhas inalteradas.
• Revelação do rastreamento de pilha ou de outras mensagens em caso de erros e exceções.
• Não fortalecer adequadamente a segurança em relação ao risco apresentado por qualquer parte da pilha.

Qual é o impacto da configuração incorreta da segurança?

O impacto pode variar desde a divulgação de informações até o comprometimento total do sistema.

Como o site Fortify pode ajudar com a configuração incorreta da segurança?

• Se você for um desenvolvedor: Fortify identifica dependências de aplicativos e arquivos de configuração durante as varreduras.
• Se você trabalha com controle de qualidade e operações: Fortify avalia dinamicamente as configurações de aplicativos e servidores em busca de problemas.
• Se você trabalha na área de Operações: Fortify fornece análises de código aberto para relatórios sobre riscos ambientais.

---

A7: Script entre sites

As falhas de XSS (Cross-Site Scripting) podem ser introduzidas quando uma entrada de usuário não confiável e não higienizada é executada como parte do HTML ou quando os usuários podem ser influenciados a interagir com links maliciosos. Exemplos são encontrados com frequência quando construções de código familiares de linguagens como JavaScript ou Flash são aceitas de fontes não confiáveis ou armazenadas para exibição posterior por outro agente de usuário. Os invasores podem executar códigos remotos no computador do usuário, roubar credenciais ou fornecer malware a partir de sites de redirecionamento.

O que torna um aplicativo vulnerável a cross-site scripting (XSS)?

Há três formas de XSS, geralmente direcionadas a agentes de usuário, como navegadores:

• XSS refletido: o aplicativo ou a API inclui entrada não confiável na saída HTML.
• XSS armazenado: o código não higienizado salvo no disco é acionado posteriormente pela ação do usuário.
• DOM XSS: aplicativos, estruturas e APIs que consomem entradas não confiáveis.

Qual é o impacto do XSS (cross-site scripting)?

• Controle da conta da vítima no aplicativo.
• Recuperação de dados do aplicativo da Web de destino.
• Modificação do conteúdo da página.

Como o site Fortify pode ajudar com o XSS (cross-site scripting)?

• Se você for um desenvolvedor: Fortify detecta vulnerabilidades de XSS no código e prevê a probabilidade de exploração.
• Se você trabalha com controle de qualidade e operações: Fortify valida o código dinamicamente em busca de entradas não higienizadas vulneráveis a XSS.
• Se você estiver em Operações: Fortify fornece registro de eventos Java e .NET, incluindo redirecionamento não autorizado.

---

A8: desserialização insegura

Falhas inseguras de desserialização podem ser introduzidas quando linguagens e estruturas permitem que dados serializados não confiáveis sejam expandidos para um objeto, geralmente quando os aplicativos da Web estão comunicando o usuário ou salvando o estado do aplicativo. Os exemplos são encontrados com frequência quando os desenvolvedores não impõem restrições aos métodos que podem ser autoexecutados durante o processo de desserialização. Os invasores aproveitam essas "cadeias de gadgets" chamadas fora da lógica do aplicativo para executar códigos remotamente, negar serviços ou obter acesso não autorizado.

O que torna um aplicativo vulnerável à desserialização insegura?

• O aplicativo desserializa dados de fontes não confiáveis.
• O aplicativo não verifica a origem ou o conteúdo antes da desserialização.
• As classes aceitáveis não são incluídas na lista de permissões para evitar a exposição desnecessária do gadget.

Qual é o impacto da desserialização insegura?

• Essas falhas podem levar a ataques de execução remota de código, um dos ataques mais graves possíveis.

Como o site Fortify pode ajudar com a desserialização insegura?

• Se você for um desenvolvedor: Fortify detecta vulnerabilidades no código-fonte e fornece análise de componentes.
• Se você trabalha com controle de qualidade e operações: Fortify instrumenta aplicativos executados dinamicamente para validar vetores de ataque.
• Se você estiver em Operações: Fortify instrumenta o registro de eventos Java e .NET, incluindo a desserialização.

---

A9: Uso de componentes com vulnerabilidades conhecidas

Essas falhas podem ser introduzidas quando estruturas e bibliotecas de código aberto ou de terceiros são introduzidas em um aplicativo e executadas com os mesmos privilégios. Exemplos são frequentemente encontrados quando o desenvolvimento baseado em componentes resulta em uma falta de compreensão dos riscos associados às dependências e componentes ou sistemas difíceis ou impossíveis de serem corrigidos. Os invasores utilizaram componentes vulneráveis para algumas das maiores violações da história, embora as vulnerabilidades possam variar do comprometimento do aplicativo à execução remota de código.

O que torna um aplicativo vulnerável a estruturas e bibliotecas de código aberto ou de terceiros?

• Eles podem ser acidentais (por exemplo, erro de codificação) ou intencionais (por exemplo, componente backdoored).
• O aplicativo ou o ambiente usa componentes sem patches ou desatualizados (um dos motivos pelos quais a modernização de aplicativos é essencial).
• Falta de varredura de vulnerabilidades em códigos de terceiros ou dependências aninhadas.
• Inventários de componentes indisponíveis ou boletins de segurança ignorados.

Qual é o impacto do uso de componentes com vulnerabilidades conhecidas?

Embora algumas vulnerabilidades conhecidas causem apenas impactos menores, algumas das maiores violações conhecidas, como Heartbleed e Shellshock, basearam-se na exploração de vulnerabilidades conhecidas em componentes compartilhados. O uso de componentes com vulnerabilidades de código conhecidas pode resultar na execução remota de código no servidor afetado, dando ao invasor o controle total da máquina.

Como o site Fortify pode ajudar na segurança de código aberto?

• Se você é desenvolvedor: Fortify fornece análise de componentes de software por meio de integrações Sonatype.
• Se você trabalha com controle de qualidade e operações: Fortify automatiza a validação dinâmica de vulnerabilidades conhecidas em tempo de execução.
• Se você estiver em Operações: Fortify registra e protege instrumentos para componentes de aplicativos Java e .NET.

---

A10: Registro e monitoramento insuficientes

Falhas insuficientes de registro e monitoramento podem ser introduzidas quando os vetores de ataque ou o mau comportamento do aplicativo não são bem compreendidos ou quando as práticas recomendadas de monitoramento de indicadores de comprometimento não são seguidas. Os exemplos são frequentemente encontrados em sistemas legados sem recursos de registro, quando os registros de testes de penetração de aplicativos não são examinados ou quando os registros não fornecem detalhes suficientes para entender o que os invasores fizeram. Os atacantes contam com uma média de cerca de 200 dias para a detecção, que normalmente é descoberta externamente, para estabelecer a persistência e se direcionar a outros sistemas vulneráveis.

O que torna um aplicativo vulnerável a registros e monitoramento insuficientes?

• Avisos e erros geram mensagens de registro inexistentes, inadequadas ou pouco claras.
• Os registros são armazenados localmente sem controles de violação e/ou não são monitorados.
• Os limites de alerta e os processos de resposta são insuficientes ou não resultam em nenhuma ação.

Qual é o impacto do registro e do monitoramento insuficientes?

A maioria dos ataques bem-sucedidos começa com a sondagem de vulnerabilidades. Permitir que essas sondagens continuem pode aumentar a probabilidade de explorações bem-sucedidas. Os invasores podem estabelecer persistência, fazer backdooring de aplicativos e sistemas operacionais, roubar dados ou, de outra forma, obter controle desapercebido e não autorizado dos sistemas. Se as informações críticas de segurança não forem registradas ou armazenadas adequadamente, não haverá nenhum rastro para que a análise forense descubra a origem do ataque. Entender que existe um problema pode se tornar mais difícil ou impossível se o invasor mantiver o controle dos recursos de registro.

Como o site Fortify pode ajudar com o registro e o monitoramento insuficientes?

• Se você for desenvolvedor: Fortify verifica os recursos de registro em aplicativos e APIs em busca de vulnerabilidades.
• Se você trabalha com controle de qualidade e operações: Fortify , as varreduras dinâmicas produzem registros de aplicativos para análise de suficiência, como testes de caneta.
• Se você estiver em Operações: Fortify instrumentos de registro e proteção para aplicativos Java e .NET.

---

O que há de novo na OWASP (2021)?

Embora tenham se passado apenas quatro anos desde que o último top 10 foi lançado em 2017, houve muitas mudanças no setor de segurança cibernética, o que nos fez pensar duas vezes sobre as preocupações de prioridade máxima ou sobre quais novas preocupações adicionar.

Três novas categorias foram introduzidas:

A04:2021

Design inseguro: Essa categoria se concentra nas falhas de design. Isso é necessário porque o movimento de deslocamento para a esquerda no desenvolvimento exige um deslocamento para a esquerda também na modelagem de ameaças.

A08:2021

Falhas de integridade de software e dados: Concentra-se em suposições sobre atualizações de software, dados críticos e o pipeline de CI/CD sem verificar a integridade que eles podem afetar. Isso também incorpora a A08:2017 - Insecure Deserialization (desserialização insegura).

A10:2021

Falsificação de solicitação do lado do servidor (SSRF): Essa categoria está principalmente entre as 10 principais da pesquisa da comunidade. Eles realmente enfatizaram essa vulnerabilidade devido à capacidade de exploração e ao impacto acima da média.

Outras alterações

As outras categorias tiveram mudanças de nome, subiram de posição ou foram consolidadas em outras categorias:

• A01:2017 - A injeção foi transferida para A:03.
• A02:2017 - Autenticação interrompida foi renomeada para Falhas de identificação e autenticação e transferida para A07.
• A03:2017 - Exposição de dados confidenciais foi transferida para A02 e renomeada como Falhas criptográficas para abordar mais completamente a causa raiz, não apenas os sintomas.
• A05:2017 - Broken Access Control foi movido para A01 porque 94% dos aplicativos testados mostraram exposição a alguma forma de Broken Access Control.
• A06:2017 - Configuração incorreta da segurança foi movida para o lugar A05.
• A07:2017 - Cross-Site Scripting (XSS) foi consolidado em A03 Injection.
• A09:2017 - Uso de componentes com vulnerabilidades conhecidas foi movido para A06 e renomeado como Componentes vulneráveis e desatualizados. Essa mudança se deveu em grande parte ao fato de a comunidade classificá-la em segundo lugar em sua lista.
• A10:2017 - Insufficient Logging & Monitoring (Registro e monitoramento insuficientes) subiu para A09 e agora se chama Security Logging and Monitoring Failures (Falhas no registro e monitoramento de segurança).

Deseja ver como o Fortify pode ajudar sua organização? Inicie sua avaliação gratuita de 15 dias do Fortify on Demand pelo OpenText™ agora