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 de segurança de aplicativos mais críticos 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 do 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 representam um risco significativo.

Embora o OWASP Top 10 seja um ótimo lugar para começar a proteger aplicativos, ele certamente não deve ser considerado 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, enganando o interpretador de consultas para que execute 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 Fortify pode ajudar com as falhas de injeção?

• Se você for um desenvolvedor: O 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: O Fortify valida o código em tempo de execução para controles de atenuação.
• Se você estiver em Operações: O Fortify oferece 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 atacantes 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 Fortify pode ajudar?

• Se você for desenvolvedor: O Fortify detecta e recomenda a correção de problemas de autenticação interrompida.
• Se você estiver em controle de qualidade ou operações: O Fortify valida a autenticação e a segurança do gerenciamento de sessões de forma dinâmica.
• Se você estiver em Operações: O 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 Fortify pode ajudar na exposição de dados confidenciais?

• Se você for um desenvolvedor: O Fortify identifica a exposição de dados confidenciais e automatiza a auditoria de problemas.
• Se você trabalha com controle de qualidade ou operações: O Fortify remove descobertas atenuadas fora do contexto do aplicativo com modelos.
• Se você estiver em Operações: Fortify instrumenta o registro e a proteção de 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 entradas XML de fontes não confiáveis, quando as definições de tipo de documento (DTDs) estão ativadas, ou que usam estruturas não corrigidas como 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 em entradas XML que resultam 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 Fortify pode ajudar com entidades externas XML?

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

A5: Controle de acesso quebrado

Os 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. Os exemplos são frequentemente encontrados quando a segurança por obscuridade é quebrada por meio da navegação forçada em páginas restritas ou quando o aplicativo define métodos complexos para o 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 Fortify pode ajudar com o controle de acesso interrompido?

• Se você for um desenvolvedor: O 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: O 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 - de serviços de rede e servidores de aplicativos a 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 Fortify pode ajudar com a configuração incorreta da segurança?

• Se você for um desenvolvedor: O Fortify identifica dependências de aplicativos e arquivos de configuração durante as varreduras.
• Se você trabalha com controle de qualidade e operações: O Fortify avalia dinamicamente as configurações de aplicativos e servidores em busca de problemas.
• Se você estiver em Operações: A Fortify fornece análises de código aberto para a geração de 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 XSS (cross-site scripting)?

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 Fortify pode ajudar com o XSS (cross-site scripting)?

• Se você for um desenvolvedor: O 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: O Fortify valida o código dinamicamente em busca de entradas não higienizadas vulneráveis a XSS.
• Se você estiver em Operações: O 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ódigo remotamente, negar serviço 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 Fortify pode ajudar com a desserialização insegura?

• Se você for um desenvolvedor: O 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 encontrados com frequência quando o desenvolvimento baseado em componentes resulta em uma falta de compreensão dos riscos associados às dependências e os componentes ou sistemas são 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 desde o comprometimento de aplicativos até a execução remota de códigos.

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

• Elas podem ser acidentais (por exemplo erro de codificação) ou intencional (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 Fortify pode ajudar na segurança de código aberto?

• Se você for desenvolvedor: O Fortify fornece análise de componentes de software por meio de integrações do Sonatype.
• Se você trabalha com controle de qualidade e operações: O Fortify automatiza a validação dinâmica de vulnerabilidades conhecidas em tempo de execução.
• Se você estiver em Operações: Fortify instrumenta o registro e a proteção 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 para 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 Fortify pode ajudar com o registro e o monitoramento insuficientes?

• Se você for desenvolvedor: O Fortify verifica os recursos de registro em aplicativos e APIs em busca de vulnerabilidades.
• Se você trabalha com controle de qualidade e operações: As varreduras dinâmicas do Fortify produzem registros de aplicativos para análise de suficiência, como testes de caneta.
• Se você estiver em Operações: Fortify: registro de instrumentos 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 que nos fizeram 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: Esta 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 norma 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 transferido para A06 e renomeado como Componentes vulneráveis e desatualizados. Essa mudança se deveu em grande parte ao fato de a comunidade ter classificado a empresa em segundo lugar em sua lista.
• A10:2017 - Registro de logs insuficientes & O monitoramento subiu para A09 e agora se chama Falhas de 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 da OpenText™ agora