Isolámos as 3 principais vulnerabilidades críticas de segurança das aplicações Web que os utilizadores do Aikido enfrentam. Este guia descreve o que são, porque são tão comuns e como corrigi-las - juntamente com algumas vulnerabilidades arriscadas que não podíamos ignorar.
Se os resolver cedo e de forma eficaz, já estará muito à frente na luta para manter a sua aplicação Web segura contra o cibercrime.
1. Vulnerabilidades de código mais comuns e críticas (SAST)
O teste estático de segurança de aplicações (SAST) é um método de teste que analisa o código-fonte em busca de vulnerabilidades no início do ciclo de desenvolvimento. É chamado um método de caixa branca 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 à fuga de dados, a bases de dados corrompidas e até ao comprometimento total do sistema. Infelizmente, trata-se de uma vulnerabilidade crítica de segurança das aplicações Web e vimos muitas contas de utilizadores do Aikido expostas a esta vulnerabilidade.
O que é a injeção NoSQL?
A injeção NoSQL é um tipo de ataque em que os hackers utilizam código malicioso para manipular ou obter acesso não autorizado a uma base de dados NoSQL. Ao contrário das injecções SQL, que visam bases de dados SQL, as injecções NoSQL exploram vulnerabilidades em bases de dados NoSQL como o MongoDB. Podem levar a fugas de dados, corrupção ou mesmo controlo total sobre a base de dados.
Porque é que esta vulnerabilidade é tão comum?
A injeção NoSQL é comum, em parte devido à crescente popularidade das bases de dados NoSQL, especialmente o MongoDB. Estas bases de dados oferecem vantagens em termos de desempenho, mas apresentam desafios de segurança únicos.
Para além disso, as bases de dados NoSQL são flexíveis na medida em que aceitam vários formatos como XML e JSON. Esta flexibilidade é óptima, mas pode levar a vulnerabilidades de segurança das aplicações Web, uma vez que as verificações de segurança padrão podem não detetar entradas maliciosas adaptadas a estes formatos.
E a vasta gama de bases de dados NoSQL, cada uma com a sua própria sintaxe e estrutura, também dificulta a criação de salvaguardas universais. Os profissionais de segurança têm de compreender os pormenores específicos de cada base de dados, o que aumenta a complexidade do processo de prevenção.
Pior ainda, e ao contrário das injecções SQL tradicionais, as injecções NoSQL podem ocorrer em diferentes partes de uma aplicação. Isto torna-as ainda mais difíceis de detetar.
Como é que se pode corrigir facilmente esta vulnerabilidade?
Utilize a validação de entrada e as consultas parametrizadas. A validação de entrada garante que as entradas do utilizador correspondem aos tipos e formatos esperados, rejeitando valores não seguros. As consultas parametrizadas impedem a incorporação de entradas não validadas.
Em geral, implemente sempre caraterísticas de segurança da base de dados, como a autenticação e a encriptação. Mantenha-se atualizado com os patches mais recentes. E certifique-se de que efectua auditorias regulares ao código e às configurações para identificar e corrigir esta e outras vulnerabilidades.
Segundo classificado: Deixar funções de depuração perigosas no código (vulnerabilidade do código: SAST)
As funções de depuração expostas permitem um reconhecimento que ajuda os atacantes a explorar os sistemas - por vezes com riscos de segurança significativos.
O que são funções de depuração 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 sistema operacional, informações do servidor e até mesmo variáveis de ambiente que podem conter chaves secretas (embora nós definitivamente não recomendamos colocar chaves secretas lá em primeiro lugar!)
Como resultado, a deteção da estrutura do seu sistema de ficheiros através destas funções de depuração pode permitir que os piratas informáticos efectuem ataques de passagem de diretórios se o seu site estiver vulnerável. Expor o phpinfo() por si só não é necessariamente um risco elevado, mas pode facilitar um pouco as coisas para os atacantes. O princípio é claro: quanto menos informações específicas os hackers tiverem sobre o seu sistema, melhor.
Porque é que esta vulnerabilidade é tão comum?
Esta vulnerabilidade de segurança das aplicações Web ocorre frequentemente porque os programadores utilizam estas funções para depuração e, por vezes, até as colocam em produção para resolução de problemas. Lançamentos apressados, falta de revisão do código e subestimação dos riscos contribuem para que estas funções sejam deixadas expostas.
Como é que se pode corrigir facilmente esta vulnerabilidade?
- Revisão do código: verifique regularmente o seu código para identificar e remover funções de depuração antes de o implementar na produção.
- Ferramentas automatizadas de verificação de vulnerabilidades: utilize uma ferramenta, como o Aikido, que possa detetar funções de depuração perigosas.
- Configurações específicas do ambiente: certifique-se de que desactiva as funções de depuração no ambiente de produção.
2. Vulnerabilidade mais comum e crítica da DAST
O teste dinâmico de segurança de aplicações (DAST) é uma técnica de teste que identifica vulnerabilidades em aplicações em execução. É chamado um método de caixa preta porque se concentra apenas no comportamento observável. O DAST mostra-lhe como o sistema pode parecer a um atacante.
Esquecer os principais cabeçalhos de segurança: HSTS e CSP (vulnerabilidade da nuvem: DAST)
A falta de uma implementação correta do HSTS e do CSP deixa as aplicações Web vulneráveis a ataques importantes como o XSS e a divulgação de informações.
O que é o CSP?
A Política de Segurança de Conteúdo (CSP) é um mecanismo de segurança que ajuda a derrotar vários ataques baseados no browser, como o cross-site scripting e o clickjacking. Fá-lo restringindo comportamentos de risco em páginas Web, tais como JavaScript em linha e funções eval() não seguras. O CSP impõe padrões mais seguros para manter a integridade e a confidencialidade do conteúdo. A principal vantagem é a proteção contra a injeção maliciosa de scripts.
Porque é que esta vulnerabilidade DAST é tão comum?
É muito comum negligenciar o HSTS e o CSP, especialmente o CSP, e os programadores dão frequentemente prioridade à funcionalidade em detrimento destes cabeçalhos.
Deveria planear a CSP no início do desenvolvimento, mas esta é frequentemente negligenciada. E quando os programadores tentam implementá-la ou adaptá-la mais tarde, isso causa conflitos, pelo que saltam completamente a CSP para prosseguir com outro trabalho. Isto deixa as aplicações desprotegidas e sujeitas a uma série de vulnerabilidades de segurança das aplicações Web.
Como é que se pode corrigir facilmente esta vulnerabilidade DAST?
- Implementar HSTS para forçar ligações apenas HTTPS. Ativar no servidor através de ficheiros de configuração ou de um WAF.
- Defina e aplique uma CSP rigorosa adaptada à sua aplicação, restringindo práticas pouco seguras como scripts em linha. Teste cuidadosamente a compatibilidade.
- Monitorizar e atualizar continuamente os cabeçalhos à medida que a aplicação evolui para manter a proteção.
3. Vulnerabilidade mais comum e crítica da nuvem (CSPM)
As ferramentas de gestão da postura de segurança na nuvem (CSPM) monitorizam continuamente os ambientes baseados na nuvem para garantir a conformidade com as normas de segurança e as melhores práticas. As ferramentas CSPM procuram configurações incorrectas de segurança e têm como objetivo atenuar os riscos.
Deixando as funções EC2 IAM vulneráveis a ataques SSRF (nuvem: CSPM)
As funções de IAM do EC2 aberto frequentemente podem permitir que os invasores se movam lateralmente e obtenham acesso não autorizado em ambientes de nuvem. O impacto potencial desse tipo de ataque pode ser devastador.
O que são funções de IAM do EC2?
As funções EC2 IAM (Identity and Access Management) no Amazon Web Services (AWS) delegam permissões para determinar as acções permitidas em recursos específicos. Permitem que as instâncias EC2 interajam de forma segura com outros serviços AWS sem terem de armazenar credenciais diretamente nas próprias instâncias.
O que é um ataque SSRF?
Um ataque de falsificação de pedidos do lado do servidor (SSRF) é quando um atacante força o servidor a efetuar pedidos a recursos internos como se fosse o próprio servidor a pedir. O atacante pode potencialmente aceder a sistemas não autorizados desta forma, contornar controlos ou mesmo executar comandos. Veja este exemplo assustador de como um ataque SSRF tomou conta da nuvem de uma startup através de um simples formulário para enviar um e-mail.
Porque é que esta vulnerabilidade CSPM é tão comum?
As funções IAM do EC2 são normalmente deixadas vulneráveis a ataques SSRF devido a configurações incorrectas de segurança ou funções demasiado permissivas. Fazer malabarismos com permissões complexas na nuvem é difícil e alguns programadores podem não compreender totalmente os riscos. Além disso, querer que os serviços funcionem bem em conjunto pode muitas vezes levar as equipas a conceder mais acesso do que o realmente necessário.
Como é que se pode corrigir facilmente esta vulnerabilidade do CSPM?
Existem algumas formas sólidas de lidar com as funções do EC2 e mitigar as vulnerabilidades de segurança das aplicações Web SSRF. Em primeiro lugar, siga o princípio do menor privilégio - permita apenas o acesso exato que é absolutamente necessário e nada mais. As funções demasiado permissivas estão a pedir problemas.
De seguida, utilize as ferramentas integradas do AWS, como grupos de segurança e ACLs de rede, para bloquear o tráfego e reduzir as potenciais aberturas para ataques SSRF. Quanto mais puder limitar o acesso, melhor.
Também é importante rever e auditar regularmente as funções para detetar qualquer acesso desnecessário que possa estar a surgir ao longo do tempo à medida que as coisas mudam. Mantenha-se a par de tudo.
E, por último, implemente ferramentas de segurança AWS focadas especificamente na deteção e prevenção de ataques SSRF antes que causem danos. Quanto mais camadas de proteção, mais seguro estará.
Vice-campeão: Tempos de execução lambda em nuvem desatualizados (nuvem: CSPM)
Quando estes ambientes de tempo de execução ficam desactualizados, podem expor as funções lambda aos atacantes.
O que são tempos de execução lambda desactualizados?
Os tempos de execução lambda desatualizados referem-se ao uso de versões mais antigas de linguagens de programação ou ambientes em funções sem servidor (lambdas). Esses tempos de execução desatualizados podem não ter os patches de segurança ou atualizações de recursos mais recentes, expondo potencialmente os aplicativos a vulnerabilidades de segurança de aplicativos Web conhecidas.
Porque é que esta vulnerabilidade CSPM é tão comum?
A vulnerabilidade resulta frequentemente de uma mentalidade de "definir e esquecer". Os programadores podem implementar lambdas com um tempo de execução específico e negligenciar a sua atualização à medida que são lançadas novas versões. Eles também podem cometer o erro de assumir que os provedores de nuvem cuidam de toda a manutenção. Embora o AWS e o Google Cloud Functions façam a manutenção dos tempos de execução com pequenos patches do sistema operacional, eles não farão grandes atualizações de linguagem. Além de tudo isso, a complexidade de gerenciar vários lambdas facilita que tempos de execução desatualizados caiam nas fendas e criem riscos extras.
Como é que se pode corrigir facilmente esta vulnerabilidade do CSPM?
Pode atenuar o risco seguindo três regras simples:
- Rever regularmente quais os tempos de execução utilizados e verificar se existem actualizações.
- Actualize para as versões suportadas mais recentes com patches de segurança.
- Utilizar ferramentas de automatização para gerir e atualizar os tempos de execução sempre que possível.
Vulnerabilidades de segurança das aplicações Web e melhores práticas
Compreender estas vulnerabilidades de segurança das 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 correcções adequadas e mantenha uma monitorização regular para manter o seu ambiente seguro e protegido.
Analise o seu ambiente com o Aikido agora mesmo para descobrir se está exposto a alguma destas vulnerabilidades.
Confira a lista de verificação de segurança do CTO de SaaS 2024 da Aikido para obter conselhos concisos sobre mais de 40 maneiras de melhorar a segurança de seu pessoal, processos, código, infraestrutura e muito mais.
.jpg)
.png)
.svg)
.png)
.png)
.png)
.jpg)
.jpg)
.jpg)
.png)