Isolamos as 3 principais vulnerabilidades críticas de segurança de aplicações web que os usuários do Aikido enfrentam. Este guia descreve o que são, por que são tão comuns e como corrigi-las — juntamente com algumas outras vulnerabilidades arriscadas que não pudemos ignorar.
Aborde-os cedo e de forma eficaz, e você já estará bem à frente na luta para manter sua aplicação web segura contra o cibercrime.
1. Vulnerabilidade de código mais comum e crítica (SAST)
Testes de segurança de aplicações estáticas (SAST) é um método de teste que escaneia o código-fonte em busca de vulnerabilidades no início do ciclo de desenvolvimento. É chamado de método white-box porque o funcionamento da aplicação é conhecido pelo testador.
Ataques de injeção NoSQL (vulnerabilidade de código: SAST)
A injeção NoSQL pode levar a vazamento de dados, bancos de dados corrompidos e até mesmo comprometimento completo do sistema. Infelizmente, é uma vulnerabilidade crítica de segurança de aplicações web e vimos muitas contas de usuários do Aikido expostas a ela.
O que é injeção NoSQL?
A injeção NoSQL é um tipo de ataque em que hackers usam código malicioso para manipular ou obter acesso não autorizado a um banco de dados NoSQL. Ao contrário das injeções SQL, que visam bancos de dados SQL, as injeções NoSQL exploram vulnerabilidades em bancos de dados NoSQL como o MongoDB. Isso pode levar a vazamentos de dados, corrupção ou até mesmo controle total sobre o banco de dados.
Por que essa vulnerabilidade é tão comum?
A injeção NoSQL é comum em parte devido à crescente popularidade dos bancos de dados NoSQL, especialmente o MongoDB. Esses bancos de dados oferecem benefícios de desempenho, mas vêm acompanhados de desafios de segurança únicos.
Além disso, os bancos de dados NoSQL são flexíveis, pois aceitam diversos formatos como XML e JSON. Essa flexibilidade é ótima, mas pode levar a vulnerabilidades de segurança em aplicações web, já que as verificações de segurança padrão podem não detectar entradas maliciosas adaptadas a esses formatos.
E a vasta gama de bancos de dados NoSQL, cada um com sua própria sintaxe e estrutura, também dificulta a criação de salvaguardas universais. Profissionais de segurança devem entender os detalhes específicos de cada banco de dados, e isso adiciona complexidade ao processo de prevenção.
Pior ainda, e ao contrário das injeções SQL tradicionais, as injeções NoSQL podem ocorrer em diferentes partes de um aplicativo. Isso as torna ainda mais difíceis de detectar.
Como você pode corrigir facilmente esta vulnerabilidade?
Use validação de entrada e consultas parametrizadas. A validação de entrada garante que as entradas do usuário correspondam aos tipos e formatos esperados, rejeitando valores inseguros. Consultas parametrizadas impedem a incorporação de entradas não validadas.
Em geral, sempre implemente recursos de segurança de banco de dados como autenticação e criptografia. Mantenha-se atualizado com os patches mais recentes. E certifique-se de realizar auditorias regulares de código e configurações para identificar e corrigir esta e outras vulnerabilidades.
Segundo lugar: Deixar funções de depuração perigosas no código (vulnerabilidade de código: SAST)
Funções de depuração expostas permitem reconhecimento que auxilia atacantes na exploração de sistemas — às vezes com risco de segurança significativo.
O que são funções de debug perigosas?
Funções de depuração como phpinfo() podem expor informações sensíveis sobre seu servidor e ambiente. Isso inclui a versão do PHP, detalhes do SO, informações do servidor e até mesmo variáveis de ambiente que podem conter chaves secretas (embora definitivamente não recomendemos colocar chaves secretas lá em primeiro lugar!).
Como resultado, a detecção da estrutura do seu sistema de arquivos através dessas funções de depuração pode permitir que hackers realizem ataques de directory traversal se o seu site for vulnerável. Expor phpinfo() por si só não é necessariamente um alto risco, mas pode tornar as coisas um pouco mais fáceis para os atacantes. O princípio é claro: quanto menos informações específicas os hackers tiverem sobre o seu sistema, melhor.
Por que essa vulnerabilidade é tão comum?
Essa vulnerabilidade de segurança em aplicações web ocorre frequentemente porque os desenvolvedores usam essas funções para depuração e, às vezes, até as enviam para produção para solução de problemas. Lançamentos apressados, falta de revisão de código e a subestimação de riscos contribuem para que essas funções fiquem expostas.
Como você pode corrigir facilmente esta vulnerabilidade?
- Revisão de código: verifique seu código regularmente para identificar e remover funções de depuração antes de implantar em produção.
- Ferramentas automatizadas de varredura de vulnerabilidades: use uma ferramenta, como o Aikido, que possa detectar funções de depuração perigosas.
- Configurações específicas do ambiente: certifique-se de desabilitar as funções de depuração no ambiente de produção.
2. Vulnerabilidade DAST mais comum e crítica
Testes Dinâmicos de Segurança de Aplicações (DAST) é uma técnica de teste que identifica vulnerabilidades em aplicações em execução. É chamado de método black-box porque se concentra apenas no comportamento observável. O DAST mostra como o sistema pode parecer para um invasor.
Esquecer cabeçalhos de segurança importantes: HSTS e CSP (vulnerabilidade de Cloud: DAST)
A falta de implementação adequada de HSTS e CSP deixa as aplicações web vulneráveis a grandes ataques como XSS e divulgação de informações.
O que é CSP?
A Política de Segurança de Conteúdo (CSP) é um mecanismo de segurança que ajuda a combater vários ataques baseados em navegador, como cross-site scripting e clickjacking. Ela faz isso restringindo comportamentos de risco em páginas web, como JavaScript inline e funções eval() inseguras. A CSP impõe padrões mais seguros para manter a integridade e a confidencialidade do conteúdo. O principal benefício é a proteção contra a injeção maliciosa de scripts.
Por que essa vulnerabilidade DAST é tão comum?
É muito comum negligenciar HSTS e CSP, especialmente CSP, e os desenvolvedores frequentemente priorizam a funcionalidade em detrimento desses cabeçalhos.
Você deve planejar o CSP no início do desenvolvimento, mas ele frequentemente é negligenciado. E quando os desenvolvedores tentam implementá-lo ou adaptá-lo mais tarde, isso causa conflitos, então eles ignoram o CSP completamente para seguir com outros trabalhos. Isso deixa as aplicações desprotegidas e sujeitas a uma série de vulnerabilidades de segurança em aplicações web.
Como você pode corrigir facilmente essa vulnerabilidade DAST?
- Implemente HSTS para forçar conexões apenas HTTPS. Habilite no servidor através de arquivos de configuração ou um WAF.
- Defina e aplique uma CSP (Content Security Policy) rigorosa, adaptada ao seu aplicativo, restringindo práticas inseguras como scripts inline. Teste cuidadosamente a compatibilidade.
- Monitore e atualize continuamente os cabeçalhos à medida que o aplicativo evolui para manter a proteção.
3. Vulnerabilidade de segurança na nuvem mais comum e crítica (CSPM)
As ferramentas de Cloud Security Posture Management (CSPM) monitoram continuamente ambientes baseados em Cloud para garantir a conformidade com padrões de segurança e melhores práticas. As ferramentas CSPM buscam por configurações de segurança incorretas e visam mitigar riscos.
Deixar roles IAM do EC2 vulneráveis a ataques SSRF (Cloud: CSPM)
Funções IAM EC2 abertas frequentemente podem permitir que invasores se movam lateralmente e obtenham acesso não autorizado em ambientes Cloud. O impacto potencial desse tipo de ataque pode ser devastador.
O que são roles EC2 IAM?
Os perfis IAM (Identity and Access Management) do EC2 na Amazon Web Services (AWS) delegam permissões para determinar ações permitidas em recursos específicos. Eles permitem que as instâncias EC2 interajam de forma segura com outros serviços AWS sem a necessidade de armazenar credenciais diretamente nas próprias instâncias.
O que é um ataque SSRF?
Um ataque de Server Side Request Forgery (SSRF) ocorre quando um invasor força o servidor a fazer requisições a recursos internos como se fosse o próprio servidor solicitando. O invasor pode potencialmente acessar sistemas não autorizados dessa forma, contornar controles ou até mesmo executar comandos. Confira este exemplo aterrorizante de como um ataque SSRF assumiu o controle da Cloud de uma startup através de um formulário simples para enviar um e-mail.
Por que essa vulnerabilidade CSPM é tão comum?
Os perfis IAM do EC2 geralmente são deixados vulneráveis a ataques SSRF devido a configurações de segurança incorretas ou perfis excessivamente permissivos. Gerenciar permissões complexas na Cloud é difícil e alguns desenvolvedores podem não compreender totalmente os riscos. Além disso, o desejo de que os serviços funcionem sem problemas juntos pode frequentemente levar as equipes a conceder mais acesso do que o realmente necessário.
Como você pode corrigir facilmente essa vulnerabilidade CSPM?
Existem algumas maneiras sólidas de lidar com roles EC2 e mitigar vulnerabilidades de segurança em aplicações web SSRF. Primeiramente, siga o princípio do menor privilégio – permita apenas o acesso exato que é absolutamente necessário e nada mais. Roles excessivamente permissivas estão pedindo por problemas.
Em seguida, utilize ferramentas AWS integradas, como security groups e network ACLs, para bloquear o tráfego e reduzir as possíveis aberturas para ataques SSRF. Quanto mais você puder limitar o acesso, melhor.
Também é importante revisar e auditar regularmente as funções para identificar qualquer acesso desnecessário que possa surgir com o tempo, à medida que as coisas mudam. Mantenha-se atento.
E, por fim, implemente ferramentas de segurança AWS focadas especificamente em detectar e prevenir ataques SSRF antes que causem danos. Quanto mais camadas de proteção, mais seguro você estará.
Segundo lugar: Runtimes de lambda Cloud desatualizados (Cloud: CSPM)
Quando esses ambientes de tempo de execução se tornam desatualizados, eles podem expor as funções lambda a atacantes.
O que são runtimes Lambda desatualizados?
Runtimes de lambda desatualizados referem-se ao uso de versões mais antigas de linguagens de programação ou ambientes em funções serverless (lambdas). Esses runtimes desatualizados podem não ter os patches de segurança mais recentes ou atualizações de recursos, potencialmente expondo aplicações a vulnerabilidades de segurança em aplicações web conhecidas.
Por que essa vulnerabilidade CSPM é tão comum?
A vulnerabilidade frequentemente surge de uma mentalidade de “configurar e esquecer”. Os desenvolvedores podem implantar lambdas com um runtime específico e negligenciar a atualização à medida que novas versões são lançadas. Eles também podem cometer o erro de assumir que os provedores de Cloud lidam com toda a manutenção. Mesmo que AWS e Google Cloud Functions mantenham os runtimes para você com patches menores de SO, eles não farão grandes atualizações de linguagem. Além de tudo isso, a complexidade de gerenciar múltiplas lambdas facilita que runtimes desatualizados passem despercebidos e criem risco adicional.
Como você pode corrigir facilmente essa vulnerabilidade CSPM?
Você pode mitigar o risco seguindo três regras simples:
- Revise regularmente quais runtimes são usados e verifique por atualizações.
- Atualize para as versões mais recentes e suportadas com patches de segurança.
- Use ferramentas de automação para gerenciar e atualizar runtimes sempre que possível.
Vulnerabilidades de segurança em aplicações web e melhores práticas
Compreender essas vulnerabilidades de segurança em aplicações web é essencial para a segurança do sistema, mas lembre-se de seguir as melhores práticas de segurança. Mantenha-se atualizado, aplique as correções apropriadas e mantenha um monitoramento regular para manter seu ambiente seguro e protegido.
Analise seu ambiente com o Aikido agora mesmo para descobrir se você está exposto a alguma dessas vulnerabilidades.
Confira o Checklist de Segurança SaaS para CTOs 2024 da Aikido para obter conselhos concisos sobre mais de 40 maneiras de melhorar a segurança em suas pessoas, processos, código, infraestrutura e muito mais.
Proteja seu software agora
.jpg)
.avif)
