O Open Web Application Security Project mantém uma lista regularmente atualizada das questões de segurança de aplicativos web mais urgentes.
Após ler este artigo, você será capaz de:
Conteúdo relacionado
Segurança de aplicativos web?
Ataque de força bruta
violação de dados
Ataque on-path
Ataque de estouro de buffer
Assine o theNET, uma recapitulação mensal feita pela Cloudflare dos insights mais populares da internet.
Copiar o link do artigo
O Open Web Application Security Project, ou OWASP, é uma organização internacional sem fins lucrativos dedicada a segurança de aplicativos web. Um dos princípios fundamentais do OWASP é que todos os seus materiais estejam disponíveis gratuitamente e facilmente acessíveis em seu site, tornando possível para qualquer pessoa melhorar a segurança de seus próprios aplicativos web. Os materiais que eles oferecem incluem documentação, ferramentas, vídeos e fóruns. Talvez seu projeto mais conhecido seja o OWASP Top 10.
O OWASP Top 10 é um relatório atualizado regularmente que descreve questões de segurança para a segurança de aplicativos web, com foco nos 10 riscos mais críticos. O relatório é elaborado por uma equipe de especialistas em segurança de todo o mundo. O OWASP refere-se ao Top 10 como um "documento de conscientização" e recomenda que todas as empresas incorporem o relatório em seus processos, a fim de minimizar e/ou mitigar os riscos de segurança.
Abaixo estão os riscos de segurança relatados no relatório OWASP Top 10 de 2017:
Os ataques de injeção acontecem quando dados não confiáveis são enviados a um intérprete de código por meio de uma entrada de formulário ou algum outro envio de dados a um aplicativo web. Por exemplo, um invasor pode inserir o código do banco de dados SQL em um formulário que espera um nome de usuário em texto não criptografado. Se a entrada do formulário não estiver devidamente protegida, isso resultará na execução do código SQL. Isso é conhecido como ataque de injeção de SQL.
Os ataques de injeção podem ser evitados validando e/ou higienizando os dados enviados pelo usuário. (Validação significa rejeitar dados de aparência suspeita, enquanto sanitização se refere à limpeza das partes de aparência suspeita dos dados.) Além disso, um administrador de banco de dados pode definir controles para minimizar a quantidade de informações que um ataque de injeção pode expor.
Saiba mais sobre como evitar injeções de SQL.
Vulnerabilidades em sistemas de autenticação (login) podem dar aos invasores acesso a contas de usuários e até mesmo a capacidade de comprometer um sistema inteiro usando uma conta de administrador. Por exemplo, um invasor pode pegar uma lista contendo milhares de combinações de nome de usuário/senhas conhecidos obtidos durante uma violação de dados e usar um script para tentar todas essas combinações em um sistema de login para ver se há alguma que funcione.
Algumas estratégias para mitigar as vulnerabilidades de autenticação exigem autenticação de dois fatores (2FA) bem como limitam ou atrasam tentativas repetidas de login usando a limitação de taxa.
Se os aplicativos da web não protegem dados sensíveis, como informações financeiras e senhas, os invasores podem obter acesso a esses dados e o vendedor os utiliza para fins nefastos. Um método popular para roubar informações confidenciais é usar um ataque on-path.
O risco de exposição de dados pode ser minimizado criptografando todos os dados sensíveis, bem como desativando o armazenamento em cache* de quaisquer informações confidenciais. Além disso, os desenvolvedores de aplicativos web devem ter o cuidado de garantir que não armazenem dados sensíveis desnecessariamente.
*Armazenamento em cache é a prática de armazenar dados temporariamente para reutilização. Por exemplo, os navegadores web geralmente armazenam em cache as páginas web para que, se um usuário revisitar essas páginas dentro de um período de tempo fixo, o navegador não precise buscar as páginas na web.
Este é um ataque contra um aplicativo web que analisa a entrada XML*. Essa entrada pode fazer referência a uma entidade externa, tentando explorar uma vulnerabilidade no analisador. Uma "entidade externa" neste contexto se refere a uma unidade de armazenamento, como um disco rígido. Um analisador XML pode ser enganado para enviar dados a uma entidade externa não autorizada, que pode transmitir dados sensíveis diretamente a um invasor.
As melhores maneiras de evitar ataques XEE são fazer com que os aplicativos da Web aceitem um tipo de dados menos complexo, como JSON**, ou pelo menos corrigir os analisadores XML e desabilitar o uso de entidades externas em um aplicativo XML.
*XML ou Extensible Markup Language é uma linguagem de marcação destinada a ser tanto legível por humanos quanto por máquinas. Devido à sua complexidade e vulnerabilidades de segurança, ela agora está sendo eliminada de uso em muitos aplicativos web.
**JavaScript Object Notation (JSON) é um tipo de notação simples e legível por humanos, frequentemente usada para transmitir dados pela internet. Embora tenha sido originalmente criada para JavaScript, a JSON é independente de linguagem e pode ser interpretada por muitas linguagens de programação diferentes.
Controle de acesso refere-se a um sistema que controla o acesso a informações ou funcionalidades. Os controles de acesso corrompidos permitem que os invasores não cumpram a autorização e executem tarefas como se fossem usuários privilegiados, como administradores. Por exemplo, um aplicativo web pode permitir que um usuário altere a conta com a qual está conectado simplesmente alterando parte de um URL, sem qualquer outra verificação.
Os controles de acesso podem ser protegidos garantindo que um aplicativo web use tokens de autorização* e defina controles rígidos sobre eles.
*Muitos serviços emitem tokens de autorização quando os usuários fazem login. Cada solicitação privilegiada que um usuário faz exigirá que o token de autorização esteja presente. Essa é uma maneira segura de garantir que o usuário seja quem diz ser, sem ter que inserir constantemente suas credenciais de login.
A configuração incorreta de segurança é a vulnerabilidade mais comum na lista e geralmente é o resultado do uso de configurações padrão ou da exibição de erros excessivamente detalhados. Por exemplo, um aplicativo pode mostrar a um usuário erros excessivamente descritivos que podem revelar vulnerabilidades no aplicativo. Isso pode ser atenuado removendo quaisquer recursos não utilizados no código e garantindo que as mensagens de erro sejam mais gerais.
As vulnerabilidades cross-site scripting ocorrem quando os aplicativos web permitem que os usuários adicionem código personalizado em um caminho de URL ou em um site que será visto por outros usuários. Esta vulnerabilidade pode ser explorada para executar código JavaScript malicioso no navegador da vítima. Por exemplo, um invasor pode enviar um e-mail para uma vítima que parece ser de um banco confiável, com um link para o site desse banco. Este link pode ter algum código JavaScript malicioso marcado no final do URL. Se o site do banco não estiver devidamente protegido contra scripts entre sites, esse código malicioso será executado no navegador da vítima quando ela clicar no link.
As estratégias de mitigação para cross-site scripting incluem fugir de solicitações HTTP não confiáveis, bem como a validação e/ou higienização de conteúdo gerado pelo usuário. O uso de estruturas de desenvolvimento web modernas, como ReactJS e Ruby on Rails, também fornece alguma proteção embutida contra cross-site scripting.
Essa ameaça tem como alvo os muitos aplicativos da web que frequentemente serializam e desserializam dados. Serialização significa pegar objetos do código do aplicativo e convertê-los em um formato que pode ser usado para outra finalidade, como armazenar os dados em disco ou transmiti-los. A desserialização é exatamente o oposto: converter dados serializados de volta em objetos que o aplicativo pode usar. A serialização é como embalar os móveis em caixas antes de uma mudança e a desserialização é como desempacotar as caixas e montar os móveis após a mudança. Um ataque de desserialização insegura é como fazer com que os carregadores mexam no conteúdo das caixas antes de serem desempacotadas.
Uma exploração de desserialização insegura é o resultado da desserialização de dados de fontes não confiáveis e pode resultar em consequências graves, como ataques DDoS e ataques de execução remota de código. Embora possam ser executadas etapas para tentar capturar os invasores, como monitorar a desserialização e implementar verificações de tipo, a única maneira segura de se proteger contra ataques de desserialização insegura é proibir a desserialização de dados de fontes não confiáveis.
Muitos desenvolvedores da web modernos usam componentes como bibliotecas e estruturas em seus aplicativos web. Esses componentes são peças de software que ajudam os desenvolvedores a evitar trabalho redundante e fornecem a funcionalidade necessária; exemplos comuns incluem estruturas de front-end como React e bibliotecas menores que costumavam adicionar ícones de compartilhamento ou teste a/b. Alguns invasores procuram vulnerabilidades nesses componentes que podem usar para orquestrar ataques. Alguns dos componentes mais populares são usados em centenas de milhares de sites; um invasor que encontre uma falha de segurança em um desses componentes pode deixar centenas de milhares de sites vulneráveis à exploração.
Os desenvolvedores de componentes costumam oferecer patches de segurança e atualizações para eliminar vulnerabilidades conhecidas, mas os desenvolvedores de aplicativos web nem sempre têm as versões corrigidas ou mais recentes dos componentes em execução em seus aplicativos. Para minimizar o risco de execução de componentes com vulnerabilidades conhecidas, os desenvolvedores devem remover componentes não utilizados de seus projetos, bem como garantir que estejam recebendo componentes de uma fonte confiável e que estejam atualizados.
Muitos aplicativos web não estão realizando etapas suficientes para detectar violações de dados. O tempo médio de descoberta de uma violação é de cerca de 200 dias após sua ocorrência. Isso dá aos invasores muito tempo para causar danos antes que haja qualquer resposta. O OWASP recomenda que os desenvolvedores da web implementem o registro e o monitoramento, bem como os planos de resposta a incidentes, para garantir que estejam cientes dos ataques aos seus aplicativos.
Para uma análise mais técnica e aprofundada do OWASP Top 10, consulte o relatório oficial .