Top 10 problemas de segurança de aplicações e como se proteger

Você sabe que sua aplicação web mais recente é inerentemente vulnerável a todos os tipos de ataques. Você também sabe que a segurança de apps nunca pode ser perfeita, mas você pode torná-la melhor amanhã do que era ontem.

O problema é que, esteja você usando ferramentas de segurança de nível empresarial (ou seja, caras e complexas) ou tenha montado um conjunto de projetos open-source em um pipeline de CI/CD ou hooks de commit do Git e esteja esperando o melhor, seu conjunto de ferramentas não consegue te ajudar a ver:

• Como seu aplicativo pode estar vulnerável devido a práticas de programação não ideais, dependências inseguras e muito mais.
• Onde as vulnerabilidades provavelmente se escondem, até LOCs individuais ou entradas em seu package.json arquivo.
• Por que você deve corrigir certas vulnerabilidades imediatamente e por que outras têm menor prioridade.

O Aikido existe para tornar a segurança de aplicativos relevante e eficiente para desenvolvedores que precisam aplicar as correções de segurança certas rapidamente e voltar a entregar código. Assim como fazemos em nossa plataforma de segurança centrada no desenvolvedor, vamos reduzir o ruído em torno das vulnerabilidades comuns e focar em três detalhes essenciais:

• O TL;DR, que vai te ensinar o suficiente para ter medo… e as palavras-chave certas para continuar sua pesquisa educacional.
• Uma resposta concisa à pergunta, “Isso me afeta?” com um claro sim ou não (✅ ou 🙅) e uma breve explicação.
• Dicas rápidas em resposta a “Como posso corrigir?” que não envolvem ferramentas caras ou refatorações custosas.

#1: SQL injection e NoSQL injection

TL;DR: Esta vulnerabilidade clássica é possível devido a entradas de usuário não sanitizadas e não validadas, o que permite que invasores executem queries diretamente contra seu banco de dados. A partir daí, eles podem extrair dados, modificar registros ou excluir à vontade, negando completamente quaisquer outras medidas de segurança de apps que você tenha implementado.

Isso me afeta?

• ✅ se seu app interage com um banco de dados SQL ou NoSQL em algum momento. Ataques de injeção existem há décadas, e ataques automatizados começarão imediatamente a sondar seus endpoints com exploits comuns.
• 🙅 se você não tem conteúdo dinâmico baseado em registros de banco de dados. Isso pode ser porque você é totalmente client-side, usando um gerador de site estático (SSG), ou fazendo renderização server-side com um banco de dados, mas nunca aceitando entrada de usuários.

Como corrijo? Primeiro e mais importante, sanitize e valide todas as entradas de usuário para eliminar caracteres ou strings indesejados. Aproveite bibliotecas e frameworks open-source que permitem queries parametrizadas, e nunca concatene entradas de usuário em uma query de banco de dados. Se você está usando Node.js, considere nosso motor de segurança open-source Runtime, que te protege autonomamente de ataques de SQL/NoSQL injection e muito mais.

#2: cross-site scripting

TL;DR: XSS é outro ataque de injeção que permite a um invasor enviar um script malicioso para outro, potencialmente coletando suas credenciais de autenticação ou dados confidenciais.

Isso me afeta?

• ✅ se seu app aceita entrada de usuário e a exibe em outro lugar como conteúdo dinâmico.
• 🙅 se você não aceita nenhuma entrada de usuário.

Como eu corrijo? Assim como nos ataques de injeção SQL/NoSQL, você deve validar a entrada do usuário ao incluir essa entrada dentro do href atributo de tags de âncora para garantir que o protocolo não seja javascript. Tenha cuidado ao usar métodos JavaScript como innerHTML ou do React dangerouslySetInnerHTML, que podem executar arbitrariamente qualquer código incorporado na string durante a saída. Independentemente da sua abordagem, sanitize a saída HTML com sanitizadores de código aberto como DOMPurify para enviar apenas HTML limpo e não executável aos seus usuários.

#3: Falsificação de requisição do lado do servidor (SSRF)

TL;DR: Ataques SSRF ocorrem quando um ator malicioso abusa do seu aplicativo para interagir com sua rede subjacente, operando-o como um proxy para saltar para serviços potencialmente mais vulneráveis ou lucrativos.

Isso me afeta?

• ✅ se seu aplicativo interage com outro serviço ou API que realiza uma operação específica com dados do usuário—mesmo que você tenha usado allowlists para restringir o tráfego apenas entre endpoints conhecidos e confiáveis.
• 🙅 se você é realmente estático.

Como eu corrijo isso? Embora uma regex para validar endereços IP ou nomes de host seja um bom começo, ela geralmente está sujeita a bypasses como codificação octal. Duas soluções mais confiáveis são usar uma allowlist e o parser de URL nativo da sua plataforma para restringir a entrada apenas a hosts seguros e conhecidos, e desabilitar redirecionamentos nas requisições fetch. Dependendo do seu framework, você também pode usar livremente projetos de código aberto—como ssrf-req-filter para Node.js—para recusar adequadamente quaisquer requisições para hosts internos.

#4: Path traversal

TL;DR: Essa falha de segurança permite que atacantes acessem arquivos e diretórios no seu servidor web referenciando arquivos usando ../ sequências ou até mesmo caminhos absolutos. Usando táticas sorrateiras como codificação dupla, atacantes podem usar hierarquias de pastas/arquivos específicas de frameworks ou nomes de arquivos comuns para encontrar informações valiosas.

Isso me afeta?

• ✅. Seu aplicativo roda em um servidor web e inclui referências ao sistema de arquivos—não há como contornar isso.

Como eu corrijo isso? Seu primeiro passo é remover quaisquer arquivos sensíveis, como aqueles contendo variáveis de ambiente ou Secrets, do diretório raiz do seu servidor web, e estabelecer um processo para evitar futuros erros.

ser nunca armazenar arquivos sensíveis, como aqueles contendo variáveis de ambiente ou Secrets, no diretório raiz do seu servidor web. Além disso, não armazene esses arquivos em nenhuma pasta destinada a ser publicamente acessível, como o /static e /public pastas de um projeto Next.js. Finalmente, remova ../ separadores de caminho e suas variantes codificadas da entrada do usuário.

Runtime também funciona fantasticamente bem para path traversal… só para constar.

#5: Injeção de Entidade Externa XML (XXE)

TL;DR: Ataques XXE exploram uma vulnerabilidade em parsers XML que permite que entidades externas, referenciadas por uma definição de tipo de documento (DTD), sejam buscadas e processadas sem validação ou sanitização. O tipo e a gravidade do ataque são limitados principalmente pelas habilidades do atacante e por quaisquer permissões/segurança em nível de SO do seu provedor de infraestrutura.

Isso me afeta?

• ✅ se você faz parsing de XML por qualquer motivo, incluindo fluxos de autenticação de single sign-on usando SAML.
• 🙅 se você não precisa lidar com XML no seu aplicativo!

Como corrigir? Desabilite a resolução de DTDs externas no seu parser XML. Provavelmente você não pode recusar DTDs completamente, pois é normal que alguns payloads XML as contenham — apenas não permita que seu parser XML faça nada com elas.

#6: Desserialização

TL;DR: Atacantes podem enviar dados maliciosos através de uma função de desserialização embutida no seu aplicativo (como unserialize() do node-serialize) para executar código remotamente, executar um ataque de negação de serviço, ou até mesmo criar um reverse shell.

Isso me afeta?

• ✅ se seu aplicativo desserializa dados diretamente da interação do usuário ou através de funções/serviços em segundo plano como cookies, formulários HTML, APIs de terceiros, caching e muito mais.
• 🙅 se você está executando um aplicativo totalmente estático sem nenhuma das opções acima.

Como corrigir? Em geral, evite desserializar dados de entrada do usuário (também conhecidos como não confiáveis). Se for necessário, aceite esses dados apenas de usuários autenticados e autorizados, com base em assinaturas confiáveis, certificados e provedores de identidade.

#7: Injeção de shell/injeção de comando

TL;DR: Seu aplicativo passa a entrada do usuário diretamente para o shell subjacente do SO no qual seu servidor web e aplicativo são executados, permitindo que atacantes executem comandos arbitrários ou naveguem pelo sistema de arquivos, muitas vezes com privilégios suficientes para extrair dados ou pivotar para outro sistema.

Isso me afeta?

• ✅ se seu aplicativo interage diretamente com o sistema de arquivos ou shell, como um comando UNIX como cat.
• 🙅 se você já usa uma API ou método de framework para passar argumentos com segurança para o comando que precisa executar, ou não precisa interagir com o sistema de arquivos/shell, como em um SSG.

Como eu corrijo? Evite aceitar entrada do usuário diretamente em comandos ou chamá-los diretamente. Em vez disso, use a API/método do seu framework, como child_process.execFile() no Node.js, que permite passar argumentos em uma lista de strings. Mesmo com essa proteção, sempre execute seus aplicativos com os privilégios mínimos necessários para a lógica de negócios exigida para evitar que um atacante "escape" do servidor web e acesse rootpastas e arquivos de acesso restrito.

E sim, estamos de volta para mais um lembrete amigável para adicionar Runtime a qualquer projeto Node.js com um comando (npm add @aikidosec/runtime || yarn install @aikidosec/runtime) para proteger instantaneamente seu aplicativo contra ataques comuns de injeção de shell/comando.

#8: Inclusão de arquivo local (LFI)

TL;DR: Ataques LFI envolvem enganar seu aplicativo para expor ou executar arquivos no sistema que hospeda seu servidor web, o que permite que invasores extraiam informações ou executem código remotamente. Enquanto o path traversal permite apenas que invasores leiam arquivos, ataques LFI executam esses arquivos dentro do seu aplicativo, expondo você a uma longa lista de vulnerabilidades de segurança de aplicativos, como execução remota de código (RCE).

Isso me afeta?

• ✅ se seu aplicativo usa o caminho para um arquivo como entrada do usuário.
• 🙅 se seu aplicativo não exige que os usuários forneçam caminhos para completar qualquer ação.

Como eu corrijo? Sempre sanitize a entrada do usuário para prevenir os métodos de path traversal discutidos acima. Se você precisar incluir arquivos no sistema de arquivos local além daqueles normalmente encontrados em pastas “seguras” /public ou /static folders, use uma allowlist de nomes de arquivos e locais que seu aplicativo tem permissão para ler e executar.

#9: Poluição de protótipo

TL;DR: Esta 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 todo o seu aplicativo, potencialmente dando-lhes acesso a dados confidenciais ou escalando ainda mais seus privilégios.

Isso me afeta?

• ✅ se você estiver usando JavaScript.
• 🙅 se você estiver usando qualquer coisa exceto JavaScript!

Como eu corrijo? Comece sanitizando chaves da entrada do usuário usando allowlists ou uma biblioteca auxiliar de código aberto. Você pode estender sua proteção usando Object.freeze() para prevenir alterações em um protótipo, ou até mesmo usando a --disable-proto=delete flag oferecida com Node.js.

#10: Redirecionamentos abertos

TL;DR: Neste vetor comum para phishing, invasores criam uma URL personalizada como https://www.example.com/abc/def?&success=true&redirectURL=https://example.phishing.com para enganar seu aplicativo e redirecionar usuários desavisados para um site malicioso. Além disso, invasores podem encadear redirecionamentos com outras vulnerabilidades para um impacto ainda maior, levando a aquisições de contas e muito mais.

Isso me afeta?

• ✅ se seu aplicativo redireciona usuários para outra página/visualização após concluir uma ação, como enviá-los para example.app/dashboard após autenticação bem-sucedida.
• 🙅 se você ainda vive essa vida de conteúdo estático.

Como eu corrijo isso? Primeiro, remova os redirecionamentos baseados em parâmetros do seu aplicativo e substitua-os por redirecionamentos fixos baseados em uma lista de permissões (allowlist) de domínios e caminhos confiáveis para os quais você pode redirecionar os usuários após eles realizarem ações específicas. Isso pode degradar ligeiramente a experiência do usuário, mas é um compromisso significativo para uma melhor segurança do aplicativo, e não um que os deixe culpando você por despesas estranhas no extrato do cartão de crédito.

O que vem a seguir para a segurança do seu aplicativo?

Se você se sente sobrecarregado pela abrangência dos ataques e todo o trabalho necessário para se proteger contra eles, saiba que você não está sozinho.

Ninguém espera que você resolva todos esses problemas de segurança e possíveis vulnerabilidades sozinho. Ataques de injeção SQL, por si só, existem há décadas, e as pessoas ainda encontram CVEs em aplicativos, frameworks e bibliotecas sofisticados o tempo todo. Isso não quer dizer que você deva ignorar esses problemas de segurança — se o seu projeto atende ao ✅ para 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 focar nas ameaças genuínas à segurança do seu aplicativo. Em dois minutos, e gratuitamente, você pode escanear repositórios e obter detalhes relevantes mais remediações guiadas para as vulnerabilidades mais críticas com base na arquitetura específica do seu aplicativo e nos recursos, funções e bibliotecas auxiliares que você implementou. Com o Aikido, você reduzirá o escopo para o que importa e implementará correções inteligentes mais rapidamente, e será informado instantaneamente sobre novos problemas de segurança introduzidos em seus últimos commits.

Em seguida, adicione o Runtime, nosso motor de segurança embarcado de código aberto, aos seus aplicativos Node.js. O Runtime protege instantânea e autonomamente seus aplicativos contra vários ataques de injeção, poluição de protótipo e path traversal, bloqueando-os no nível do servidor, mas sem o custo e a complexidade de firewalls de aplicação web ou plataformas de gerenciamento de segurança de aplicação baseadas em Agente. O Runtime lhe dá a confiança de que seu aplicativo e usuários estão seguros contra esses problemas de segurança comuns, mas também pode alimentar dados em tempo real de volta ao Aikido para lhe dar visibilidade sobre os vetores de ataque atuais e ajudar a priorizar as correções.

Agora você está no caminho certo, com uma visão mais clara sobre:

• Como seu aplicativo é vulnerável de mais maneiras do que você poderia ter imaginado.
• Onde você deve focar seu tempo e atenção para corrigir os problemas mais críticos primeiro.
• Por que a segurança de aplicativos e a varredura de vulnerabilidades não são um esforço único, mas um processo contínuo—um processo muito mais fácil com Aikido.