Sabe que a sua aplicação Web mais recente é inerentemente vulnerável a todos os tipos de ataques. Também sabe que a segurança das aplicações nunca pode ser perfeita, mas pode torná-la melhor amanhã do que era ontem.
O problema é que, quer esteja a utilizar ferramentas de segurança de nível empresarial (ou seja, dispendiosas e complexas), quer tenha juntado uma mão-cheia de projectos de código aberto num pipeline CI/CD ou ganchos de confirmação Git e esteja à espera do melhor, o seu kit de ferramentas não o pode ajudar a ver:
- Como a sua aplicação pode ser vulnerável devido a práticas de programação menos que ideais, dependências inseguras e muito mais.
- Onde as vulnerabilidades estão muito provavelmente escondidas, até LOCs individuais ou entradas no seu
package.jsonficheiro. - Porque é que deve corrigir imediatamente determinadas vulnerabilidades e porque é que outras são menos prioritárias.
O Aikido existe para tornar a segurança das aplicações relevante e eficiente para os programadores que precisam de aplicar rapidamente as correcções de segurança corretas e voltar a enviar o código. Tal como fazemos na nossa plataforma de segurança centrada no programador, vamos reduzir o ruído em torno das vulnerabilidades comuns e concentrar-nos em três pormenores essenciais:
- O TL;DR, que lhe ensinará apenas o suficiente para ter medo... e as palavras-chave certas para continuar a sua pesquisa educacional.
- Uma resposta concisa à pergunta "Isto afecta-me?" com um claro sim ou não (✅ ou 🙅) e uma breve explicação.
- Dicas rápidas em resposta a "Como posso resolver isto?" que não envolvam ferramentas caras ou refacções dispendiosas.
#1: Injeção SQL && Injeção NoSQL
TL;DR: Esta vulnerabilidade clássica é possibilitada pela entrada de dados do utilizador não higienizados e não validados, o que permite que os atacantes executem consultas diretamente na sua base de dados. A partir daí, podem extrair dados, modificar registos ou eliminar à vontade, anulando completamente quaisquer outras medidas de segurança da aplicação que tenha implementado.
Isto afecta-me?
- ✅ se a sua aplicação interagir com uma base de dados SQL ou NoSQL em qualquer ponto. Os ataques de injeção existem há décadas, e os ataques automatizados começarão imediatamente a sondar os seus pontos finais com explorações comuns.
- 🙅 se não tiver conteúdo dinâmico baseado nos registos da base de dados. Isto pode dever-se ao facto de estar inteiramente do lado do cliente, utilizando um gerador de sítios estáticos (SSG), ou de estar a fazer a renderização do lado do servidor com uma base de dados, mas sem nunca aceitar contributos dos utilizadores.
Como é que o posso resolver? Antes de mais, higienize e valide todas as entradas do utilizador para eliminar caracteres ou cadeias de caracteres indesejados. Aproveite as bibliotecas e estruturas de código aberto que permitem consultas parametrizadas e nunca concatene a entrada do usuário em uma consulta de banco de dados. Se estiver a utilizar Node.js, considere o nosso motor de segurança de código aberto Runtime, que o projecta autonomamente contra ataques de injeção SQL/NoSQL e muito mais.
#2: Scripting entre sítios (XSS)
TL;DR: XSS é outro ataque de injeção que permite a um atacante enviar um script malicioso para outro, potencialmente recolhendo as suas credenciais de autenticação ou dados confidenciais.
Isto afecta-me?
- Se a sua aplicação aceitar a entrada de dados do utilizador e os enviar para outro local como conteúdo dinâmico.
- 🙅 se não aceitar a entrada do utilizador de todo.
Como é que o arranjo? Tal como acontece com os ataques de injeção SQL/NoSQL, deve validar a entrada do utilizador quando inclui essa entrada dentro do href das etiquetas âncora para garantir que o protocolo não é javascript. Tenha cuidado ao utilizar métodos JavaScript como interiorHTML ou o perigosamenteSetInnerHTMLque pode executar arbitrariamente qualquer código embutido na string durante a saída. Independentemente da sua abordagem, higienize a saída HTML com higienizadores de código aberto como DOMPurificar para enviar apenas HTML limpo e não executável aos seus utilizadores.
#3: Falsificação de pedidos do lado do servidor (SSRF)
TL;DR: Os ataques SSRF acontecem quando um ator malicioso abusa da sua aplicação para interagir com a sua rede subjacente, operando-a como um proxy para saltar para serviços potencialmente mais vulneráveis ou lucrativos.
Isto afecta-me?
- ✅ se a sua aplicação fizer interface com outro serviço ou API que execute uma operação específica com dados do utilizador - mesmo que tenha utilizado listas de permissões para restringir o tráfego apenas entre pontos finais conhecidos e fiáveis.
- 🙅 se estiveres verdadeiramente estático.
Como é que o posso corrigir? Embora um regex para validar endereços IP ou nomes de host seja um bom começo, ele geralmente é propenso a desvios como a codificação octal. Duas soluções mais fiáveis são utilizar uma lista de permissões e o analisador de URL nativo da sua plataforma para restringir a entrada apenas a anfitriões seguros e conhecidos, e desativar os redireccionamentos nos pedidos de pesquisa. Dependendo da sua estrutura, você também pode aproveitar livremente projetos de código aberto - como ssrf-req-filter para Node.js - para recusar adequadamente quaisquer solicitações para hosts internos.
#4: Travessia de caminhos
TL;DR: Esta falha de segurança permite que os atacantes acedam a ficheiros e diretórios no seu servidor Web através de ficheiros de referência utilizando ../ sequências ou mesmo caminhos absolutos. Utilizando tácticas sorrateiras como a codificação dupla, os atacantes podem utilizar hierarquias de pastas e ficheiros específicas da estrutura ou nomes de ficheiros comuns para encontrar informações valiosas.
Isto afecta-me?
- ✅. A sua aplicação é executada num servidor Web e inclui referências ao sistema de ficheiros - nada de contornar esta questão.
Como é que o posso resolver? O primeiro passo é remover todos os ficheiros sensíveis, como os que contêm variáveis de ambiente ou segredos, do diretório raiz do seu servidor Web e estabelecer um processo para evitar mais erros.
é nunca armazenar ficheiros sensíveis, como os que contêm variáveis de ambiente ou segredos, no diretório raiz do seu servidor Web. Além disso, não armazene esses arquivos em nenhuma pasta destinada a ser acessível publicamente, como o diretório /estático e /público pastas de um Projeto Next.js. Por fim, tira ../ separadores de caminhos e as suas variantes codificadas a partir da entrada do utilizador.
O tempo de execução também funciona fantasticamente bem para a travessia de caminhos... só estou a dizer.
#5: Injeção de entidade externa XML (XXE)
TL;DR: Os ataques XXE aproveitam uma fraqueza nos analisadores XML que permite que entidades externas, referenciadas por uma definição de tipo de documento (DTD), sejam obtidas e processadas sem validação ou sanitização. O tipo e a gravidade do ataque são limitados principalmente pelas competências do atacante e por quaisquer permissões/segurança ao nível do SO do seu fornecedor de infra-estruturas.
Isto afecta-me?
- Se analisar XML por qualquer motivo, incluindo fluxos de autenticação de início de sessão único utilizando SAML.
- 🙅 se não tiveres de lidar com XML na tua aplicação!
Como é que o posso resolver? Desabilite a resolução de DTDs externas em seu analisador XML. Provavelmente não pode recusar DTDs por completo, uma vez que é normal que alguns payloads XML os contenham - apenas não deixe o seu analisador XML fazer nada com eles.
#6: Deserialização
TL;DR: Os atacantes podem enviar dados maliciosos através de uma função de desserialização incorporada na sua aplicação (como unserialize() do node-serialize) para executar código remotamente, executar uma negação de serviço ou até mesmo criar uma shell reversa.
Isto afecta-me?
- ✅ se a sua aplicação desserializar dados diretamente da interação do utilizador ou através de funções/serviços em segundo plano, como cookies, formulários HTML, APIs de terceiros, armazenamento em cache e muito mais.
- 🙅 se estiver a executar uma aplicação totalmente estática sem nenhuma das opções acima.
Como é que o posso resolver? Em geral, evite desserializar dados de entrada do usuário (também conhecidos como não confiáveis). Se for necessário, aceite apenas esses dados de utilizadores autenticados e autorizados com base em assinaturas, certificados e fornecedores de identidade fiáveis.
#7: Injeção de shell/injeção de comando
TL;DR: A sua aplicação passa a entrada do utilizador diretamente para o shell subjacente do SO no qual o seu servidor Web e a sua aplicação são executados, permitindo que os atacantes executem comandos arbitrários ou atravessem o sistema de ficheiros, muitas vezes com privilégios suficientes para extrair dados ou passar para outro sistema.
Isto afecta-me?
- ✅ se o seu aplicativo interage com o sistema de arquivos ou shell diretamente, como um comando UNIX como
gato. - 🙅 se já utilizar uma API ou método da estrutura para passar argumentos com segurança para o comando que precisa de executar, ou se não precisar de interagir com o sistema de ficheiros/shell, como num SSG.
Como é que o arranjo? Evite aceitar a entrada do utilizador diretamente nos comandos ou chamá-los diretamente. Em vez disso, use a API/método da sua estrutura, como processo_criança.execFile() no Node.js, que permite passar argumentos numa lista de cadeias de caracteres. Mesmo com essa proteção, execute sempre as suas aplicações com os privilégios mínimos necessários para a lógica comercial exigida para evitar que um atacante "escape" do servidor Web e aceda a raiz-apenas pastas e ficheiros.
E sim, estamos de volta para mais um lembrete amigável para acrescentar Tempo de execução a qualquer projeto Node.js com um comando (npm add @aikidosec/runtime || yarn install @aikidosec/runtime) para proteger instantaneamente a sua aplicação contra ataques comuns de injeção de shell/comando.
#8: Inclusão de ficheiros locais (LFI)
TL;DR: Os ataques LFI envolvem enganar a sua aplicação para expor ou executar ficheiros no sistema que executa o seu servidor Web, o que permite aos atacantes extrair informações ou executar código remotamente. Enquanto o path traversal apenas permite que os atacantes leiam ficheiros, os ataques LFI executam esses ficheiros dentro da sua aplicação, abrindo-o a uma lista de vulnerabilidades de segurança da aplicação, como a execução remota de código (RCE).
Isto afecta-me?
- ✅ se a sua aplicação utilizar o caminho para um ficheiro como entrada do utilizador.
- 🙅 se a sua aplicação não exigir que os utilizadores forneçam caminhos para concluir qualquer ação.
Como é que o arranjo? Limpe sempre a entrada do utilizador para evitar os métodos de passagem de caminho discutidos acima. Se tiver de incluir ficheiros no sistema de ficheiros local para além dos que se encontram tipicamente em "safe" /público ou /estático utilize uma lista de permissões de nomes de ficheiros e localizações que a sua aplicação tem permissão para ler e executar.
#9: Protótipo de poluição
TL;DR: Este Vulnerabilidade específica do JavaScript permite que um invasor manipule os objetos globais do seu aplicativo usando __proto__. O novo objeto é então herdado em toda a aplicação, dando-lhes potencialmente acesso a dados confidenciais ou aumentando ainda mais os seus privilégios.
Isto afecta-me?
- ✅ se estiver a utilizar JavaScript.
- 🙅 se estiver a utilizar algo que não seja JavaScript!
Como é que o arranjo? Comece por higienizar as chaves da entrada do utilizador utilizando listas de permissões ou uma biblioteca auxiliar de código aberto. Você pode estender sua proteção usando Object.freeze() para impedir alterações a um protótipo, ou mesmo utilizando o --disable-proto=delete oferecida com o Node.js.
#10: Abrir redireccionamentos
TL;DR: Neste vetor comum de phishing, os atacantes criam um URL personalizado como https://www.example.com/abc/def?&success=true&redirectURL=https://example.phishing.com para enganar a sua aplicação e redirecionar utilizadores desprevenidos para um site malicioso. Além disso, os atacantes podem encadear os redireccionamentos com outras vulnerabilidades para obter um impacto ainda maior, conduzindo a aquisições de contas e muito mais.
Isto afecta-me?
- ✅ se o seu aplicativo redireciona os usuários para outra página/visualização após a conclusão de uma ação, como enviá-los para
example.app/dashboardapós uma autenticação bem sucedida. - 🙅 se ainda estiveres a viver essa vida gerada pela estática.
Como é que o posso corrigir? Em primeiro lugar, remova os redireccionamentos baseados em parâmetros da sua aplicação e substitua-os por redireccionamentos fixos baseados numa lista de permissões de domínios e caminhos fidedignos para os quais pode redirecionar os utilizadores depois de estes realizarem acções específicas. Isto pode degradar ligeiramente a experiência do utilizador, mas é um compromisso significativo para uma melhor segurança da aplicação, e não um compromisso que os deixe a culpá-lo pelas despesas estranhas no extrato do cartão de crédito.
O que se segue para a segurança da sua aplicação?
Se está a sentir-se sobrecarregado pelo âmbito dos ataques e por todo o trabalho necessário para se proteger contra eles, saiba que não está sozinho.
Ninguém espera que você mesmo resolva todos esses problemas de segurança e possíveis vulnerabilidades. Os ataques de injeção de SQL por si só existem há décadas, e as pessoas ainda estão encontrando CVEs em aplicativos, estruturas e bibliotecas sofisticadas o tempo todo. Isso não quer dizer que você também deva encarar esses problemas de segurança com um grão de sal - se o seu projeto atende ao ✅ de qualquer um desses 10 principais problemas de segurança de aplicativos, você deve começar a agir.
Primeiro, inscreva-se no Aikido para começar a concentrar-se nas ameaças genuínas à segurança da sua aplicação. Em dois minutos, e gratuitamente, pode analisar repositórios e obter detalhes relevantes, além de correcções guiadas para as vulnerabilidades mais críticas com base na arquitetura específica da sua aplicação e nas caraterísticas, funções e bibliotecas auxiliares que implementou. Com o Aikido, você reduzirá o escopo ao que importa e implementará correções inteligentes mais rapidamente, além de ser informado instantaneamente sobre novos problemas de segurança introduzidos em seus últimos commits.
Em seguida, adicione o Runtime, nosso mecanismo de segurança incorporado de código aberto, às suas aplicações Node.js. O Runtime protege instantaneamente e de forma autónoma as suas aplicações contra vários ataques de injeção, poluição de protótipos e de passagem de caminhos, bloqueando-os ao nível do servidor, mas sem o custo e a complexidade das firewalls de aplicações Web ou das plataformas de gestão de segurança de aplicações baseadas em agentes. O tempo de execução dá-lhe a confiança de que a sua aplicação e os seus utilizadores estão a salvo destes problemas de segurança comuns, mas também pode fornecer dados em tempo real ao Aikido para lhe dar visibilidade sobre os vectores de ataque actuais e ajudá-lo a dar prioridade às correcções.
Agora já está com o pé direito, com uma ideia mais clara:
- Como a sua aplicação é vulnerável de mais formas do que poderia ter pensado.
- Onde deve concentrar o seu tempo e atenção para resolver primeiro os problemas mais críticos.
- Porque é que a segurança das aplicações e a verificação de vulnerabilidades não é um esforço único, mas um processo contínuo - um processo muito mais fácil com o Aikido.
.png)
.svg)
.png)
.png)
.png)
.jpg)
.jpg)
.jpg)
.jpg)
.png)