OWASP Top 10 2017 dos principais riscos à segurança de aplicações web

O OWASP (sigla de Open Web Application Security Project) lançou oficialmente em novembro de 2017 a atualização dos 10 principais riscos de segurança de aplicações web e, portanto, apresentamos neste post o OWASP Top 10 2017.

De acordo com o OWASP, algumas mudanças significativas ocorreram desde a última vez que a lista foi divulgada em 2013 e contribuíram para a atualização do Top 10 Security Risks, isso inclui, aplicativos de página única e o domínio do JavaScript como principal linguagem de programação na web.

Para quem não conhece, o OWASP é uma organização sem fins lucrativos dedicada a fornecer informações imparciais e práticas sobre segurança de aplicativos.

A seguir, identifica-se cada um dos riscos de segurança de aplicações web de acordo com o OWASP Top 10 2017, oferecendo, ainda, soluções e práticas recomendadas para preveni-las ou corrigi-las.

Para acesso aos detalhes, clique no título desejado ou acesse o PDF completo.

A1:2017 – Injection

As falhas de injeção, como a injeção SQL, NoSQL, OS e LDAP, ocorrem quando dados não confiáveis são enviados para um interpretador como parte de um comando ou query. Os dados hostis do invasor podem enganar o interpretador para executar comandos não intencionais ou acessar dados sem a devida autorização.

Consideração: Testes de segurança de aplicativos podem detectar facilmente falhas de injeção. Os desenvolvedores devem usar consultas parametrizadas ao codificar para evitar falhas de injeção.

A2:2017 – Broken Authentication

As funções de aplicativos relacionadas à autenticação e ao gerenciamento de sessão geralmente são implementadas incorretamente, permitindo que invasores comprometam senhas, chaves ou tokens de sessão ou explorem outras falhas de implementação para assumir temporariamente ou permanentemente identidades de outros usuários.

Consideração: A autenticação de dois fatores, como o Google Authenticator, Duo Security e outros aplicativos dedicados, reduzem o risco de contas comprometidas.

A3:2017 – Sensitive Data Exposure

Muitas aplicações web e APIs não protegem de forma adequada os dados confidenciais, como dados financeiros, de saúde e PII. Os atacantes podem roubar ou modificar esses dados que não estão bem protegidos para conduzir fraudes em cartões de crédito, roubos de identidade ou outros crimes. Os dados sensíveis podem ser comprometidos sem proteção extra, como criptografia em repouso ou em trânsito, e requer precauções especiais quando trocados com o navegador.

Consideração: A criptografia de dados em repouso e em trânsito pode ajudá-lo a cumprir os regulamentos de proteção de dados.

A4:2017 – XML External Entities (XXE)

Muitos processadores XML desatualizados ou mal configurados avaliam referências de entidades externas em documentos XML. As entidades externas podem ser usadas para divulgar arquivos internos usando o manipulador URI do arquivo, compartilhamento de arquivos internos, scan de portas internas, execução de código remoto e ataques de negação de serviço.

Consideração: A metodologia Static Application Security Testing (sigla de SAST, ou Testes de Segurança de Aplicativos Estáticos) pode descobrir esse problema inspecionando dependências e configurações.

A5:2017 – Broken Access Control

As restrições sobre o que os usuários autenticados são autorizados a fazer geralmente não são devidamente aplicadas. Os atacantes podem explorar essas falhas para acessar funcionalidades e/ou dados não autorizados, como acessar contas de outros usuários, visualizar arquivos sensíveis, modificar dados de outros usuários, alterar direitos de acesso, etc.

Consideração: O teste de penetração (penetration testing) é essencial para a detecção de controles de acesso não funcionais; outros métodos de teste apenas detectam onde os controles de acesso estão faltando.

A6:2017 – Security Misconfiguration

A falta de configuração de segurança é o problema mais comum. Isso geralmente é resultado de configurações padrão inseguras, configurações incompletas ou ad hoc, armazenamento em nuvem aberta, cabeçalhos HTTP mal configurados e mensagens de erro contendo informações confidenciais. Não só todos os sistemas operacionais, frameworks, bibliotecas e aplicativos devem ser configurados de forma segura, mas devem ser corrigidos/atualizados em tempo hábil.

Consideração: A metodologia Dynamic Application Secutiry Test (sigla de DAST, ou Testes de Segurança de Aplicativos Dinâmicos) pode detectar configurações erradas, como APIs vazadas.

A7:2017 – Cross-Site Scripting (XSS)

As falhas XSS ocorrem sempre que um aplicativo inclui dados não confiáveis em uma nova página da Web sem validação adequada ou escapando, ou atualiza uma página da Web existente com dados fornecidos pelo usuário usando uma API do navegador que pode criar HTML ou JavaScript. O XSS permite que os invasores executem scripts no navegador da vítima, que podem sequestrar sessões de usuários, desfigurar (deface) em sites ou redirecionar o usuário para sites maliciosos.

Consideração: O treinamento do desenvolvedor complementa os testes de segurança para ajudar os programadores a impedirem cross-site scripting com melhores práticas de desenvolvimento, como codificação de dados e validação de entrada.

A8:2017 – Insecure Deserialization

A desserialização insegura geralmente leva a uma execução remota de código. Mesmo que as falhas de desserialização não resultem na execução remota de código, elas podem ser usadas para realizar ataques, incluindo ataques de replay (ou ataques de repetição), ataques de injeção e ataques de escalação de privilégios.

Consideração: As ferramentas de segurança de aplicativos podem detectar falhas de desserialização, mas os testes de penetração (penetration testing) são necessários com certa frequência para validar o problema.

A9:2017 – Using Components with Known Vulnerabilities

Componentes, como bibliotecas, frameworks e outros módulos de software, são executados com os mesmos privilégios que o aplicativo. Se um componente vulnerável for explorado, esse ataque pode facilitar uma séria perda de dados ou o controle do servidor. Aplicativos e APIs que usam componentes com vulnerabilidades conhecidas podem prejudicar as defesas de aplicativos e ativar vários ataques e impactos.

Consideração: Análise de composição de software realizada ao mesmo tempo em que a análise estática pode identificar versões de componentes inseguros.

A10:2017 – Insufficient Logging & Monitoring

O registro e o monitoramento insuficientes, juntamente com a integração ausente ou ineficaz com a resposta a incidentes, permitem que o ataque aos sistemas persistam e migrem para mais sistemas, extraiam e destruam dados. A maioria dos estudos de infração mostram que o tempo para detectar uma violação é de mais de 200 dias, normalmente detectado por terceiros em vez de processos internos ou monitoramento.

Consideração: Pense como um invasor e use testes de penetração para descobrir se você possui monitoramento suficiente; examine seus registros após o pentest que realizar.

Conclusão

Este é um assunto que não tem conclusão, não é mesmo? =P

Brincadeiras à parte, mas esses 10 riscos de aplicações são perigosos porque podem permitir que invasores plantem malwares, roubem dados ou assumam completamente seus computadores ou servidores web.

Portanto, conhecer os Padrões de Conformidade da OWASP é o primeiro passo para o desenvolvimento de códigos seguros.

Para saber mais detalhes sobre a OWASP Top 10, acesse o projeto oficial.