0
0
Os aplicativos da Web são os principais vetores que os invasores usam para realizar violações. De acordo com o “Relatório de Investigações de Violação de Dados” (PDF) da Verizon , os aplicativos da Web foram o caminho para aproximadamente 70% de todas as violações estudadas.
Depois de realizar mais de 300 testes de penetração de aplicativos da Web, entendo o porquê. Os desenvolvedores continuam cometendo os mesmos erros de segurança que criam vulnerabilidades . Eles geralmente não usam estruturas seguras e tentam escrever códigos de segurança e processos de autenticação por conta própria.
É importante observar quanta pressão os desenvolvedores estão sofrendo para lançar produtos no mercado rapidamente. Eles são recompensados com base em quantos recursos podem introduzir o mais rápido possível, não necessariamente com a maior segurança possível. Isso leva a atalhos de segurança e, no futuro, a vulnerabilidades em aplicativos da Web .
Cinco lições para aplicativos mais seguros
Os testadores de caneta desempenham o papel de advogado do diabo e fazem engenharia reversa do que os desenvolvedores de aplicativos criam para mostrar onde e como os invasores obtêm acesso. Os resultados destacaram erros fundamentais comuns. Aqui estão cinco lições que as empresas de desenvolvimento de software podem aprender para tornar seus aplicativos mais seguros.
- Os invasores ainda estão aproveitando o cross-site scripting (XSS). O XSS tem sido uma vulnerabilidade de aplicativo da Web popular. Em 2021, ele saiu da lista dos 10 melhores do Open Web Application Security Project (OWASP) devido a melhorias nas estruturas de desenvolvimento de aplicativos, mas ainda é evidente em quase todos os testes de penetração que realizamos.
Muitas vezes, é considerado de baixo risco, mas os riscos XSS podem ser graves, incluindo aquisição de contas, roubo de dados e comprometimento total da infraestrutura de um aplicativo. Muitos desenvolvedores pensam que o uso de uma biblioteca de validação de entrada madura e a configuração de atributos de cookie HttpOnly adequados são suficientes, mas os bugs XSS ainda encontram uma maneira quando o código personalizado é usado. Veja os sites do WordPress, por exemplo – um ataque XSS que visa um administrador é crítico porque as credenciais permitem que o usuário carregue plug-ins, executando assim cargas maliciosas semelhantes a códigos no servidor. - Scanners automatizados não vão longe o suficiente. Se você estiver verificando apenas aplicativos da Web usando ferramentas automatizadas, há uma boa chance de que as vulnerabilidades passem despercebidas. Essas ferramentas usam fuzzing – um método que injeta dados malformados em sistemas – mas essa técnica pode criar falsos positivos.
Os scanners geralmente não estão atualizados com o desenvolvimento moderno da Web e não oferecem os melhores resultados para aplicativos JavaScript de página única, WebAssembly ou Graph. Vulnerabilidades complicadas precisam de uma carga útil criada para validá-las, tornando as ferramentas automatizadas menos eficazes.
Há um elemento humano necessário para a análise mais precisa e detalhada de vulnerabilidades e explorações, mas esses scanners podem ser um recurso complementar para encontrar rapidamente o que está ao alcance. - Quando a autenticação é caseira, geralmente é muito fraca. A autenticação é tudo para proteger um aplicativo da Web. Quando os desenvolvedores tentam criar seu próprio fluxo de trabalho de senha esquecida, eles normalmente não o fazem da maneira mais segura.
Os testadores de penetração geralmente obtêm acesso às informações de outros usuários ou têm privilégios excessivos que não estão de acordo com sua função. Isso cria problemas de controle de acesso horizontal e vertical que podem permitir que invasores bloqueiem usuários de suas contas ou comprometam o aplicativo.
É tudo sobre como esses protocolos são implementados. A autenticação Security Assertion Markup Language (SAML), por exemplo, é um protocolo de logon único que está se tornando mais popular como meio de aumentar a segurança, mas se você implementá-lo incorretamente, você - Os invasores visam falhas na lógica de negócios. Os desenvolvedores analisam os recursos para determinar se eles cumprem o caso de uso de um cliente. Muitas vezes, eles não estão olhando do outro lado da lente para identificar como um invasor pode usar esse recurso de maneira maliciosa.
Um ótimo exemplo é o carrinho de compras de um site de comércio eletrônico. É crítico para os negócios, mas muitas vezes não é seguro, o que cria vulnerabilidades graves, como zerar o total na finalização da compra, adicionar itens após a finalização da compra ou substituir produtos por outros SKUs.
É difícil culpar os desenvolvedores por se concentrarem no caso de uso principal e não reconhecerem outros usos normalmente nefastos. Seu desempenho é baseado na entrega do recurso. Os executivos precisam ver o outro lado da moeda e entender que a lógica de negócios deve corresponder à lógica de segurança. Os recursos com maior valor comercial, como carrinho de compras ou fluxo de trabalho de autenticação, provavelmente não são o trabalho de um desenvolvedor júnior. - Não há “fora do escopo” em um bom teste de penetração. Os aplicativos da Web podem rapidamente se tornar complexos com base em quantos recursos e ativos vão para eles. Os servidores de API de back-end que permitem a funcionalidade do aplicativo principal precisam ser considerados.
É importante compartilhar todos esses ativos externos e como eles se conectam ao que os desenvolvedores criaram com auditores de segurança que realizam testes de penetração. O desenvolvedor pode considerar esses ativos como “fora do escopo” e, portanto, não é responsável por eles, mas um invasor não respeitaria essa linha na areia. Como mostram os testes de penetração, nada está “fora do escopo”.
Uma Questão de Equilíbrio
Quando as empresas de desenvolvimento de software entendem alguns desses riscos comuns de antemão, elas podem ter um melhor envolvimento com os auditores de segurança e tornar os testes de penetração menos dolorosos. Nenhuma empresa quer atrasar seus desenvolvedores, mas ao equilibrar criatividade com estruturas de segurança, os desenvolvedores sabem onde têm liberdade e onde precisam se alinhar com as proteções que mantêm os aplicativos seguros.
FONTE: DARK READING