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 resume questões de segurança de aplicativos web baseado nos 10 riscos mais críticos. O relatório é elaborado por uma equipe de especialistas em segurança mundial. 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:
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.
Se os aplicativos da web não protegerem dados confidenciais, como informações financeiras e senhas, usando criptografia, os invasores poderão obter acesso a esses dados e vendê-los ou utilizá-los para fins criminosos. Eles também podem roubar informações confidenciais usando um ataque on-path.
O risco de exposição de dados pode ser minimizado criptografando todos os dados confidenciais, autenticando todas as transmissões e 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 estejam armazenando dados confidenciais 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.
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.
A categoria de injeção também inclui ataques de cross-site scripting (XSS), que anteriormente eram sua própria categoria no relatório de 2017. As estratégias de mitigação para cross-site scripting incluem fugir de solicitações HTTP não confiáveis, bem como usar estruturas de desenvolvimento web modernas, como ReactJS e Ruby on Rails, que fornecem alguma proteção embutida contra cross-site scripting.
Em geral, 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 higienizaçã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.
O design inseguro inclui uma série de pontos fracos que podem ser incorporados na arquitetura de um aplicativo. Ele se concentra no design de um aplicativo, não em sua implementação. O OWASP lista o uso de perguntas de segurança (por exemplo, "Em que rua você cresceu?") para recuperação de senhas como um exemplo de um fluxo de trabalho que é inseguro por design. Não importa a perfeição com que esse fluxo de trabalho seja implementado por seus desenvolvedores, o aplicativo ainda estará vulnerável, porque mais de uma pessoa pode saber a resposta a essas perguntas de segurança.
O uso da modelagem de ameaças antes da implantação de um aplicativo pode ajudar a mitigar esses tipos de vulnerabilidades.
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.
A categoria configuração incorreta de segurança inclui o ataque de entidades externas XML (XEE), anteriormente sua própria categoria no relatório de 2017. 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 passar dados confidenciais diretamente para um invasor. As melhores maneiras de evitar ataques XEE são fazer com que os aplicativos 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, seu uso está sendo eliminado em muitos aplicativos web.
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 correções 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.
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.
Muitos aplicativos hoje dependem de plug-ins de terceiros e outras fontes externas para sua funcionalidade, e nem sempre garantem que as atualizações e os dados dessas fontes não sejam adulterados e originados de um local esperado. Por exemplo, um aplicativo que aceita automaticamente atualizações de uma fonte externa pode estar vulnerável a um invasor que faça upload de suas próprias atualizações maliciosas, que seriam distribuídas para todas as instalações desse aplicativo. Esta categoria também inclui explorações de desserialização insegura: esses ataques são o resultado da desserialização de dados de fontes não confiáveis e podem resultar em consequências graves, como ataques DDoS e ataques de execução remota de código.
Para ajudar a garantir que dados e atualizações não tenham sido violados, os desenvolvedores de aplicativos devem usar assinaturas digitais para verificar atualizações, verificar suas cadeias de suprimentos de software e garantir que os pipelines de integração contínua/implantação contínua (CI/CD) tenham um forte controle de acesso e estejam configurados corretamente.
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.
A falsificação de solicitações do lado do servidor (SSRF) é um ataque no qual alguém envia uma solicitação de URL a um servidor que faz com que o servidor busque um recurso inesperado, mesmo que esse recurso esteja protegido de outra forma. Um invasor pode, por exemplo, enviar uma solicitação para www.example.com/super-secret-data/, mesmo que os usuários da web não devam ser capazes de navegar para esse local e obter acesso aos dados supersecretos da resposta do servidor.
Há uma série de mitigações possíveis para os ataques de SSRF e uma das mais importantes é validar todos os URLs provenientes de clientes. URLs inválidos não devem resultar em uma resposta direta e bruta do servidor.
Para uma análise mais técnica e aprofundada do OWASP Top 10, consulte o relatório oficial .