As 10 Principais Vulnerabilidades de Segurança em Aplicações Web Que Toda Equipe Deve Conhecer

‍Introdução: Qual foi a última vez que você examinou a segurança da sua aplicação web além de apenas fazê-la funcionar? Aqui está a verdade assustadora: cada campo de formulário, endpoint de API, script de terceiros e arquivo de configuração em sua aplicação pode ser um vetor de ataque se não for verificado. Aplicações web modernas são mais ricas e complexas do que nunca – e isso significa uma crescente superfície de ataque para invasores. De fato, dados recentes mostram que aplicações web estão envolvidas em quase metade dos incidentes de segurança. Desde os infames riscos do Top 10 OWASP até CVEs recém-descobertos, as vulnerabilidades web não são teoria abstrata – elas estão por trás de violações reais que acontecem em organizações de todos os tamanhos.

O objetivo deste artigo é destacar as vulnerabilidades mais críticas de aplicações web, tanto do ponto de vista de frontend quanto de backend. Abordaremos riscos conhecidos do Top 10 OWASP juntamente com exploits de alto perfil (como Log4Shell e outros) e erros comuns de codificação que desenvolvedores cometem em projetos reais. Para cada vulnerabilidade, explicaremos o que é, daremos um exemplo ou incidente real e descreveremos como mitigá-la. Você também verá  – destacando como a plataforma de segurança voltada para o desenvolvedor da Aikido (com recursos como varredura de código, detecção de segredos, SAST e varredura IaC) pode ajudar a detectar ou prevenir esses problemas antes que eles afetem você em produção.

A Lista:

1. Ataques de Injeção (SQL, Command, LDAP)
2. Cross-site scripting (XSS)
3. Autenticação quebrada
4. Controle de acesso quebrado
5. Configurações de segurança incorretas
6. Exposição de dados sensíveis e Vazamento de Secrets
7. Uso de Componentes com Vulnerabilidades Conhecidas
8. Cross-Site Request Forgery (CSRF)9. Server-Side Request Forgery (SSRF)
10. Desserialização Insegura

O Que São Vulnerabilidades de Aplicações Web?

Vulnerabilidades de aplicações web são fraquezas ou falhas no design, implementação ou configuração de uma aplicação web que invasores podem explorar para comprometer o sistema. Elas podem variar desde erros de codificação, como falhas de injeção, até configurações incorretas, como deixar um console de administração aberto, ou problemas de lógica que permitem que usuários contornem verificações de segurança. Algumas vulnerabilidades permitem que invasores roubem dados ou assumam contas de usuário; outras possibilitam o comprometimento total do servidor ou a disseminação de malware para seus usuários. Muitos dos bugs "clássicos" são conhecidos há anos (e são resumidos pela lista do Top 10 OWASP), mas permanecem difundidos devido às pilhas de tecnologia em evolução e ao simples erro humano.

Abaixo, abordaremos as principais vulnerabilidades de segurança de aplicações web que todo desenvolvedor e equipe de DevSecOps deve conhecer. Esta não é uma lista exaustiva de todos os bugs existentes, mas sim os problemas mais comuns e perigosos que vemos em uso atualmente – juntamente com dicas para evitá-los.

As Principais Vulnerabilidades de Aplicações Web (Frontend e Backend)

As seguintes vulnerabilidades são extraídas do Top 10 OWASP e de exploits recentes do mundo real. Cada uma representa um risco sério para aplicações web. Vamos explorá-las uma a uma:

1. Ataques de Injeção (SQL, Command, LDAP, etc.)

O que é: Falhas de injeção ocorrem quando dados não confiáveis são enviados a um interpretador como parte de um comando ou consulta. As mais notórias são a injeção SQL (entrada maliciosa em consultas SQL) e a injeção de comando de SO (entrada maliciosa executada no servidor). Quando uma aplicação inclui diretamente a entrada do usuário em consultas de banco de dados, comandos de shell, consultas LDAP ou filtros ORM sem validação adequada, invasores podem “injetar” seus próprios comandos. Isso pode levar a roubo de dados, corrupção de dados ou tomada completa do host. De acordo com a OWASP, a injeção é um risco de alto nível e agora até engloba o cross-site scripting em sua classificação.

Exemplo: Um exemplo de alto perfil é a violação do MOVEit Transfer em 2023. Invasores exploraram uma injeção SQL zero-day (CVE-2023-34362) na aplicação web de compartilhamento de arquivos MOVEit, permitindo-lhes executar código remoto no servidor. O grupo de ransomware Clop usou essa falha para roubar dados de centenas de organizações, demonstrando como um único bug de injeção pode escalar para uma violação massiva. Este incidente mostrou que SQLi não é apenas um problema "antigo" – ainda está muito vivo e pode ser catastrófico.

Impacto: Ataques de injeção bem-sucedidos podem ser devastadores. Uma injeção SQL pode extrair senhas de usuários, registros pessoais ou dados de negócios. A injeção de comando de SO pode dar a um invasor um shell em seu servidor, levando ao comprometimento total da infraestrutura. Em suma, vulnerabilidades de injeção frequentemente resultam em perda severa de dados, comprometimento de contas ou execução remota de código – tornando-as favoritas entre os invasores.

Prevenção: A chave é nunca misturar entrada não confiável diretamente com comandos. Use consultas parametrizadas ou instruções preparadas para acesso ao banco de dados (para que o interpretador SQL nunca confunda entrada com código). Para comandos de SO, evite construir strings de comando; use APIs seguras ou uma lista de permissões para valores esperados. A validação de entrada e a codificação de saída também são camadas defensivas importantes. O SAST (análise estática de código) alimentado por IA da Aikido pode ajudar a identificar padrões de injeção perigosos em seu código antes da implantação. Por exemplo, a varredura de código da Aikido sinalizará ocorrências onde a entrada do usuário é concatenada em instruções SQL ou passada para chamadas de sistema sem sanitização. Ao integrar tais scanners em seu CI/CD ou IDE, você pode detectar e corrigir automaticamente falhas de injeção. Com a Aikido, você poderia ter identificado aquela consulta SQL vulnerável muito antes dos invasores!

2. Cross-site scripting (XSS)

O que é: Cross-site scripting é um tipo de injeção que visa os navegadores dos usuários. Uma vulnerabilidade XSS permite que um invasor injete scripts maliciosos do lado do cliente (geralmente JavaScript) em páginas web visualizadas por outros usuários. Ao contrário do SQLi, que visa seu banco de dados, o XSS permite que um invasor manipule o conteúdo visto pelos usuários – potencialmente roubando tokens de sessão, desfigurando a UI ou entregando malware. O XSS se apresenta em tipos como XSS refletido (o script malicioso vem de uma requisição e é refletido na resposta), XSS armazenado (o script é armazenado no servidor, por exemplo, em um campo de comentário de banco de dados, e servido a cada visualizador), e XSS baseado em DOM (a vulnerabilidade está no código do lado do cliente que modifica a página).

Exemplo: Um dos incidentes de XSS mais famosos foi a violação da British Airways de 2018. O grupo de hackers Magecart injetou um script malicioso em uma biblioteca JS de terceiros (Feedify) usada no site da BA. Este script capturou detalhes de cartão de crédito da página de pagamento, enviando os dados para um servidor controlado por invasores. Os invasores conseguiram roubar informações pessoais e de cartão de crédito de cerca de 380.000 transações antes que a violação fosse descoberta. Em essência, uma vulnerabilidade XSS em um componente da cadeia de suprimentos levou a um roubo massivo de dados – e multas caras para a BA. Outros exemplos de XSS no mundo real incluem um bug na página web do Fortnite que poderia ter exposto milhões de contas, e um XSS no site do eBay que invasores exploraram para sequestrar contas de vendedores de alto valor.

Impacto: O XSS compromete principalmente os usuários, mas pode afetar indiretamente a segurança da sua aplicação (e, definitivamente, sua reputação). Invasores podem roubar cookies de sessão (para personificar usuários), realizar ações como a vítima (como transferências de fundos ou alterações de senha se as proteções CSRF estiverem ausentes) ou exibir formulários de phishing para enganar usuários. Se a sessão de um usuário administrador for sequestrada via XSS, o invasor pode obter controle total da aplicação. Mesmo sites não sensíveis devem se preocupar com XSS – ninguém quer que seu site sirva prompts de login falsos ou redirecione usuários para kits de exploit.

Prevenção: A defesa contra XSS envolve codificação de saída e políticas de segurança de conteúdo. Sempre que sua aplicação exibir dados fornecidos pelo usuário em uma página web, ela deve escapar/codificar adequadamente esses dados para o contexto (HTML, JavaScript, CSS, etc.) para que não possam ser interpretados como código. A maioria dos frameworks web possui bibliotecas de template ou codificação – use-as consistentemente (evite criar HTML a partir de strings brutas). Implemente uma Política de Segurança de Conteúdo (CSP) robusta para limitar quais scripts podem ser executados em suas páginas (embora a CSP seja uma segunda linha de defesa). A varredura de código da Aikido pode detectar áreas onde a entrada do usuário é inserida na página sem sanitização adequada. Por exemplo, se você usar inadvertidamente innerHTML ou concatenação de strings para injetar dados do usuário no DOM, o analisador estático do Aikido o sinalizará. O Aikido também pode identificar a falta de flags HTTP-only ou cabeçalhos de Content Security Policy através de sua varredura de configuração. Ao detectar esses problemas precocemente, você evita o próximo ataque estilo Magecart aos seus usuários. (Bônus: a base de conhecimento de vulnerabilidades integrada do Aikido pode até sugerir práticas de codificação seguras, como o uso de textContent em vez de innerHTML para evitar DOM XSS.)

3. Autenticação Quebrada

O que é: Autenticação Quebrada refere-se a fraquezas na forma como um site lida com o login e o gerenciamento de sessão – coisas como credenciais de usuário, IDs de sessão, redefinição de senha e recuperação de conta. Se os atacantes puderem comprometer facilmente senhas, chaves ou tokens de sessão devido a uma implementação deficiente, isso é autenticação quebrada. Armadilhas comuns incluem políticas de senha fracas (ou nenhum Rate limiting no login, permitindo força bruta), falha em armazenar senhas com segurança (por exemplo, armazenar hashes em texto simples ou sem salt), usar IDs de sessão previsíveis ou inseguros, não invalidar sessões no logout e lógica falha de 'lembrar-me' ou redefinição de senha. Qualquer falha que permita a um atacante fingir ser outra pessoa (adivinhando ou roubando credenciais/sessão) ou fazer login sem as credenciais adequadas se enquadra nesta categoria. De acordo com a OWASP, essas falhas de autenticação podem levar a tomadas de conta e violações de dados significativas.

Exemplo: Não é preciso ir longe para encontrar exemplos – uma grande parte das violações decorre de credenciais comprometidas. Na verdade, 81% das violações relacionadas a hacking em 2022 foram devido a senhas fracas ou roubadas. Um incidente específico: no início de 2023, a Uber divulgou que a conta de um contratado foi comprometida porque o contratado reutilizou uma senha encontrada em uma violação anterior. Os atacantes entraram nos sistemas internos da Uber usando essa conta – essencialmente uma falha de autenticação (reutilização de senha e falta de MFA). Outro exemplo: uma violação em 2024 em uma empresa de serviços financeiros onde a ausência de autenticação multifator (MFA) permitiu que atacantes usassem senhas vazadas para acessar contas, afetando milhões (isso foi observado no contexto do incidente de dados de clientes da Snowflake – embora a plataforma da Snowflake não tenha sido diretamente hackeada, a autenticação fraca do lado do usuário levou à violação). Esses casos mostram que, mesmo que o código do seu aplicativo seja sólido, práticas de autenticação fracas (por usuários ou desenvolvedores) podem abrir uma grande porta.

Impacto: A autenticação quebrada pode levar ao comprometimento total da conta para qualquer usuário no sistema – de clientes comuns a administradores. Se um atacante obtiver credenciais de usuário (via força bruta, credential stuffing usando senhas vazadas, ou explorando uma falha na sua lógica de autenticação), ele pode se passar por esse usuário e acessar todos os seus dados. É particularmente grave se contas de administrador ou privilegiadas forem comprometidas – o atacante poderia roubar todos os dados, alterar configurações ou avançar para redes internas. Mesmo em menor escala, contas de usuário comprometidas podem resultar em fraude, violações de privacidade e perda de confiança do usuário.

Prevenção: Defesas de autenticação robustas são essenciais. Imponha requisitos de senha fortes e use hashing (com um algoritmo forte como bcrypt ou Argon2) mais salting para senhas armazenadas – nunca armazene senhas em texto puro. Implemente autenticação multifator para contas ou ações sensíveis; o MFA pode frustrar muitos ataques baseados em senha. Use gerenciamento de sessão seguro: torne os IDs de sessão aleatórios e imprevisíveis, defina-os para expirar e invalide as sessões ao fazer logout. Evite expor IDs de sessão em URLs (use cookies com flags Secure e HttpOnly). Implemente proteção contra força bruta (bloqueios ou CAPTCHAs após várias tentativas de login falhas) e monitore para credential stuffing.

‍A plataforma do Aikido pode ajudar detectando fraquezas comuns de autenticação em seu código e configuração. Por exemplo, o scanner do Aikido o alertará se você estiver usando um método fraco de hashing de senha (ou pior, armazenando senhas em texto simples). Ele também pode detectar se os cookies de sessão não estão marcados como Secure/HttpOnly, ou se as configurações de segurança do seu framework web (como as do Django ou Express) estão mal configuradas para o gerenciamento de sessão. Além disso, a detecção de segredos do Aikido pode alertá-lo se você acidentalmente codificar uma chave de API ou senha de conta de serviço em seu código (evitando que esses Secrets se tornem um login de backdoor para um atacante). Ao detectar esses problemas precocemente, você impõe um esquema de autenticação mais forte desde o início.

4. controle de acesso quebrado (falhas de autorização e IDOR)

O que é: O controle de acesso quebrado é atualmente o risco de aplicativo web mais crítico, #1, de acordo com a OWASP. Refere-se a falhas na aplicação da autorização – ou seja, as regras sobre o que os usuários autenticados têm permissão para fazer. Mesmo que um usuário seja quem ele diz ser (autenticação bem-sucedida), o aplicativo deve restringi-lo apenas a dados e funções permitidos. Falhas comuns de controle de acesso incluem não verificar funções/permissões de usuário em certas ações, confiar na aplicação do lado do cliente (que atacantes podem contornar), ou expor referências a objetos internos sem verificar a propriedade. Uma variante extremamente comum é IDOR (Insecure Direct Object Reference), onde um aplicativo usa IDs fornecidos pelo usuário (como números de conta, IDs de documento, etc.) para buscar dados sem confirmar que o usuário atual tem permissão para acessar o objeto especificado. Por exemplo, se GET /api/orders/12345 retorna o pedido #12345 para qualquer usuário que o acesse, um atacante poderia simplesmente mudar o ID para 12346 e recuperar o pedido de outro usuário – um cenário clássico de IDOR. Outros exemplos incluem a falta de verificações de acesso em endpoints de administração 'ocultos', ou bugs de escalonamento de privilégios onde um usuário comum pode se tornar um administrador ajustando um parâmetro ou token JWT.

Exemplo: A prevalência de controle de acesso quebrado é impressionante – um estudo descobriu que 94% dos aplicativos testados apresentavam alguma forma de fraqueza no controle de acesso. Quanto a incidentes reais, considere a vulnerabilidade da API da Kia Motors (2024): Pesquisadores descobriram que, fornecendo apenas o VIN ou o número da placa de um carro, eles poderiam chamar certos endpoints da API Kia/Hyundai e executar comandos de veículo remotamente (como destrancar portas), sem qualquer token de autenticação. Essa falha crítica se resumiu a uma falha de controle de acesso em uma API – o sistema não garantiu que a solicitação vinha de um proprietário autorizado. Outro exemplo é a violação da MOVEit que mencionamos anteriormente: embora fosse principalmente um problema de SQLi, foi observado que a falta de autenticação no endpoint vulnerável permitiu que os atacantes o explorassem diretamente. Também vemos regularmente bugs de IDOR em aplicativos web onde um usuário pode visualizar ou modificar os dados de outro: por exemplo, uma vulnerabilidade de 2021 na API de uma popular plataforma de mídia social permitiu que atacantes enumerassem IDs de perfil de usuário para buscar informações de perfil privadas que deveriam ter sido restritas. Em suma, controles de acesso quebrados frequentemente levam a escalonamento de privilégios vertical (usuário se torna administrador) ou horizontal (usuário A pode agir como usuário B).

Impacto: Quando o controle de acesso falha, as consequências variam de vazamentos de dados a uma tomada completa do sistema. Um atacante pode ler dados sensíveis de outros usuários (violando a confidencialidade) ou modificar dados que não deveria (violando a integridade). Em casos graves, o controle de acesso quebrado pode permitir que uma parte externa obtenha privilégios de administrador – o que significa o fim do jogo para o aplicativo. Por exemplo, um IDOR em um site de e-commerce poderia permitir que alguém visse pedidos ou informações pessoais de outros clientes; uma verificação de administrador ausente poderia permitir que um usuário comum acessasse um /admin/deleteUser endpoint e apagar dados. Essas falhas levam diretamente a violações de confidencialidade e são frequentemente muito fáceis para atacantes explorarem uma vez descobertas (nenhum payload sofisticado é necessário – apenas uma URL ou parâmetro alterado).

Prevenção: O mantra aqui é “negar por padrão.” Toda requisição que acessa uma operação sensível ou registro de dados deve estar sujeita a verificações de controle de acesso no lado do servidor (server-side). Use frameworks ou middlewares que centralizem a aplicação de papéis/permissões. Por exemplo, se você tem papéis de usuário, garanta que toda função de administrador verifique o papel do usuário no servidor (nunca confie apenas em verificações do lado do cliente, como ocultar botões de administrador na UI). Para acesso em nível de objeto (como visualizar ou editar um recurso por ID), implemente verificações de propriedade – por exemplo, confirme que o orderId solicitado pertence ao usuário autenticado que faz a requisição. Testes automatizados podem ajudar a verificar se o acesso não autorizado está sendo bloqueado corretamente.

‍O Aikido ajuda você a identificar controle de acesso quebrado de algumas maneiras. Primeiro, o pentest autônomo (Aikido Attack) do Aikido pode sondar dinamicamente seu aplicativo em execução em busca dessas falhas – por exemplo, ele pode simular um atacante com uma conta de usuário normal tentando acessar APIs de administrador ou dados de outros usuários, e relatará qualquer bypass de privilégio bem-sucedido. No lado do código, a análise estática do Aikido pode identificar rotas ou controladores com verificações de autenticação ausentes (especialmente em frameworks onde as rotas devem ser anotadas com papéis). Se sua base de código usa infraestrutura como código (infrastructure-as-code) ou configuração para políticas de acesso (por exemplo, regras de API gateway ou IAM da Cloud), os scanners do Aikido também podem avaliá-las. Ao usar o Aikido para testar continuamente a lógica de autorização, você detecta aqueles erros de “oops, esqueci de impor o login naquele endpoint” antes que os atacantes o façam. Lembre-se sempre: exceto para recursos verdadeiramente públicos, tudo deve exigir autorização adequada – o Aikido pode ajudar a verificar se você está aderindo a esse princípio.

5. Configurações de Segurança Incorretas

O que é: Mesmo uma aplicação perfeitamente codificada pode ser prejudicada por uma configuração insegura. configuração de segurança incorreta é uma categoria ampla que abrange qualquer configuração ou definição insegura na infraestrutura ou na pilha de aplicações. Isso inclui coisas como: deixar credenciais padrão ativas nos servidores (por exemplo, admin/admin), usar ficheiros de configuração ou secrets padrão, deixar pontos finais sensíveis (como painéis de administração de bases de dados ou painéis de controlo na nuvem) acessíveis ao público, não desativar listagens de diretórios num servidor web, ter cabeçalhos HTTP mal configurados (por exemplo, cabeçalhos de segurança ausentes) ou esquecer de definir permissões adequadas no armazenamento na nuvem. As configurações incorretas geralmente surgem de configurações de desenvolvimento/teste que não são reforçadas para produção ou simplesmente de erros humanos na implementação. Em ambientes de nuvem, uma configuração incorreta clássica é deixar um bucket S3 ou armazenamento de blobs do Azure publicamente legível quando contém dados privados. Essencialmente, é quando o seu sistema está a dizer «Bem-vindos, invasores, a porta está aberta!» devido a um descuido nas configurações.

Exemplo: Infelizmente, configurações incorretas causam muitas violações reais. Um caso impressionante de 2024: 1,3 milhões de registos de pacientes ficaram expostos num servidor público durante duas semanas devido a uma simples configuração incorreta do servidor. Não foi necessária nenhuma exploração – os dados foram essencialmente publicados para o mundo devido a um descuido. Outro exemplo: um incidente na Prudential Financial (2024), onde uma única configuração incorreta num sistema de controlo de acesso permitiu que invasores acessassem discretamente 2,5 milhões de registos de clientes. E quem pode esquecer a violação da Capital One (2019) – embora tenha envolvido SSRF como mecanismo de ataque, a causa principal foi uma firewall de aplicação web mal configurada firewall de aplicação ambiente AWS, que permitiu que o invasor acessasse recursos internos. No caso da Capital One, um bucket de armazenamento AWS S3 com dados confidenciais ficou acessível assim que a configuração incorreta do WAF foi explorada, levando ao roubo de mais de 100 milhões de registos de clientes. Esses exemplos ressaltam que, muitas vezes, pequenos erros de configuração (como uma porta aberta, uma credencial esquecida ou um controle de segurança desativado) podem ter consequências enormes.

Impacto: O impacto varia dependendo do que foi mal configurado. Na extremidade inferior, uma configuração incorreta pode "apenas" vazar algumas informações não críticas (por exemplo, uma página de erro detalhada revelando versões de software – útil para invasores, mas não uma violação por si só). No extremo, uma configuração incorreta pode levar diretamente a um comprometimento total: uma interface administrativa aberta pode permitir que invasores façam login (especialmente se as credenciais padrão não foram alteradas), um bucket de armazenamento em nuvem aberto pode expor milhões de registos ou uma configuração de segurança desativada pode permitir explorações triviais. As configurações incorretas estão entre as principais causas de violações de dados em serviços em nuvem. Elas também são facilmente detectadas por invasores – existem motores de busca e bots que procuram continuamente por coisas como painéis abertos do Elasticsearch/Kibana, portas de banco de dados expostas ou buckets públicos. Em resumo, as configurações incorretas podem transformar seu aplicativo seguro em um “parque de diversões para hackers” se você não tomar cuidado.
‍
Prevenção: diligência e automação são fundamentais. Altere sempre as palavras-passe e chaves padrão (nada deve funcionar com "admin/admin" ou padrões semelhantes). Fortaleça as configurações do seu servidor e estrutura: por exemplo, desative os modos de depuração e aplicativos de amostra em produção, certifique-se de que a navegação no diretório esteja desativada e aplique os cabeçalhos de segurança recomendados (Content Security Policy, X-Frame-Options, etc.). Use o princípio do privilégio mínimo para recursos na nuvem – se um serviço ou bucket não precisar de acesso público, bloqueie-o (e para aqueles que precisam ser públicos, certifique-se de que eles exponham apenas o que é pretendido). Revise regularmente sua infraestrutura como código ou configurações de ambiente em relação aos padrões de segurança.

varredura IaC a auditoria de configuraçãoAikidopodem ser um salva-vidas aqui. Se você usa Terraform, CloudFormation, Kubernetes YAML ou similares, Aikido verificar se há configurações inseguras (como grupos de segurança abertos, buckets S3 públicos ou configurações de criptografia ausentes). Ele também pode verificar se há configurações incorretas no seu ambiente de nuvem em execução. Para servidores web e aplicativos, os scanners Aikidosinalizam cabeçalhos de segurança ausentes ou mensagens de erro excessivamente detalhadas. Além disso, Aikidoproteção em tempo de execução podem monitorizar o uso anormal que pode indicar que alguém está a explorar uma configuração incorreta. A lição a ser aprendida é tornar as verificações de configuração parte do seu pipeline – Aikido automatizar isso, detectando os erros do tipo «ops, deixei esse bucket público» antes da implementação. E fique sempre atento a novos patches e atualizações; às vezes, as configurações incorretas resultam da execução de software desatualizado com fraquezas padrão conhecidas.

6. exposição de dados sensíveis Secrets

O que é: esta categoria abrange falhas na proteção adequada de informações confidenciais, tanto dados do utilizador como chaves secretas.exposição de dados sensíveis(também chamada de falhas criptográficas) significa que uma aplicação não protege adequadamente os dados em trânsito ou em repouso. Exemplos incluem não usar HTTPS para comunicações confidenciais, usar criptografia fraca ou nenhuma criptografia para dados armazenados (como hashes sem sal para senhas ou dados pessoais em texto simples em um backup de banco de dados) ou expor acidentalmente dados por meio de depuração ou logs. Intimamente relacionado está secrets – quando os desenvolvedores inadvertidamente expõem se você não tomar cuidado.

Prevenção: diligência e automação são fundamentais. Sempre altere as palavras-passe e chaves padrão (nada deve ser executado com "admin/admin" ou padrões semelhantes). Fortaleça as configurações do servidor e da estrutura: por exemplo, desative os modos de depuração e os aplicativos de amostra em produção, certifique-se de que a navegação no diretório esteja desativada e aplique os cabeçalhos de segurança recomendados (Content Security Policy, X-Frame-Options, etc.). Use o princípio do privilégio mínimo para recursos na nuvem – se um serviço ou bucket não precisar de acesso público, bloqueie-o (e para aqueles que precisam ser públicos, certifique-se de que eles exponham apenas o que é pretendido). Revise regularmente as configurações da sua infraestrutura como código ou ambiente em relação aos padrões de segurança.

varredura IaC a auditoria de configuraçãoAikidopodem ser um salva-vidas aqui. Se você usa Terraform, CloudFormation, Kubernetes YAML ou similares, Aikido verificar se há configurações inseguras (como grupos de segurança abertos, buckets S3 públicos ou configurações de criptografia ausentes). Ele também pode verificar se há configurações incorretas no seu ambiente de nuvem em execução. Para servidores web e aplicativos, os scanners Aikidosinalizam cabeçalhos de segurança ausentes ou mensagens de erro excessivamente detalhadas. Além disso, Aikidoproteção em tempo de execução podem monitorizar o uso anormal que pode indicar que alguém está a explorar uma configuração incorreta. A lição a ser aprendida é tornar as verificações de configuração parte do seu pipeline – Aikido automatizar isso, detectando os erros do tipo «ops, deixei esse bucket público» antes da implementação. E fique sempre atento a novos patches e atualizações; às vezes, as configurações incorretas resultam da execução de software desatualizado com fraquezas padrão conhecidas.

6. exposição de dados sensíveis Secrets

O que é: esta categoria abrange falhas na proteção adequada de informações confidenciais, tanto dados do utilizador como chaves secretas.exposição de dados sensíveis(também chamada de falhas criptográficas) significa que uma aplicação não protege adequadamente os dados em trânsito ou em repouso. Os exemplos incluem não usar HTTPS para comunicações confidenciais, usar criptografia fraca ou nenhuma criptografia para dados armazenados (como hashes sem sal para senhas ou dados pessoais em texto simples em um backup de banco de dados) ou expor acidentalmente dados por meio de depuração ou logs. Intimamente relacionado está secrets – quando os desenvolvedores inadvertidamente expõem secrets chaves de API, senhas de banco de dados, credenciais ou tokens, seja codificando-os no código, deixando-os em ficheiros de configuração enviados para repositórios ou armazenando-os no código do lado do cliente. Uma quantidade impressionante de secrets vazada por desenvolvedores a cada ano (muitas vezes no GitHub público). Resumindo, se a sua aplicação não encriptar corretamente o que deve ser encriptado, ou se você for descuidado com informações confidenciais e chaves, estará a convidar invasores a obter esses dados sem muito esforço.

Exemplo: Um dos lados desta questão são os dados não encriptados. Um exemplo simples, mas ilustrativo: há muitos anos, os sites às vezes aceitavam credenciais de login por HTTP simples – esses dias já não existem mais, mas mesmo agora ainda ocorrem erros. Em 2023, descobriu-se que uma importante integração de API transmitia dados pessoais de saúde sem a encriptação adequada (devido a uma cadeia de certificados TLS mal configurada), expondo informações privadas na rede. Outro exemplo: se um ficheiro de backup de base de dados for armazenado num bucket de nuvem não seguro (ligado a uma configuração incorreta), todos os dados pessoais nele contidos podem ficar expostos — isso aconteceu com uma companhia aérea em 2022, que vazou centenas de milhares de registos de clientes porque o backup não estava criptografado nem tinha controlo de acesso.

No secrets , o problema é endémico. Só em 2024, os investigadores detetaram quase 23,8 milhões de novos secrets codificados secrets commits públicos do GitHub – um aumento de 25% em relação ao ano anterior. Essa «proliferação de segredos» levou a violações reais. Por exemplo, em 2023, um invasor vazou todo o código-fonte do New York Times de um repositório privado, supostamente explorando credenciais vazadas. Noutro caso, uma empresa de inteligência empresarial (Sisense) teve uma credencial interna vazada num fórum público, que os invasores usaram para acessar dados confidenciais de clientes. Mais perto de casa para os desenvolvedores: quantas vezes já ouvimos falar de uma chave secreta da AWS acidentalmente enviada para o GitHub, apenas para que mineradores de criptomoedas ou piores a usassem em questão de minutos? Esses exemplos mostram que não proteger os dados com criptografia e não manter secrets em segredo pode levar diretamente a violações de dados e acesso não autorizado.

Impacto: Se dados confidenciais do utilizador (informações pessoais, dados financeiros, registos de saúde, etc.) forem expostos, o impacto geralmente é sentido tanto pelos utilizadores (violações de privacidade, risco de roubo de identidade) quanto pela empresa (penalidades regulatórias, danos à reputação). Por exemplo, registos de saúde expostos podem resultar em multas e processos judiciais ao abrigo da HIPAA. Palavras-passe ou números de cartões de crédito expostos conduzem obviamente a fraudes. Entretanto, secrets vazados secrets como chaves API ou tokens) podem ser um bilhete dourado para um invasor: por exemplo, uma palavra-passe de base de dados vazada pode permitir que um invasor se conecte e descarregue toda a sua base de dados; uma chave API da nuvem vazada pode permitir que eles ativem servidores (à sua conta) ou acessem dados confidenciais na nuvem. Uma credencial de administrador vazada pode, às vezes, comprometer um aplicativo inteiro ou até mesmo uma frota de sistemas. Não é surpresa que o Relatório de Custo de Violação de Dados da IBM consistentemente considere as violações envolvendo credenciais comprometidas e dados confidenciais entre as mais caras (tanto em dólares quanto em perda de confiança).

Prevenção: há dois aspetos aqui: proteger dados confidenciais e gerir secrets . Para dados confidenciais de utilizadores/empresas, use sempre HTTPS (aplique TLS para todo o tráfego e use protocolos/configurações modernos). Nunca transmita informações confidenciais, como senhas ou tokens, em texto simples, mesmo em comunicações internas. Em repouso, encripte campos de dados críticos (muitos bancos de dados e serviços de armazenamento em nuvem oferecem encriptação em repouso; use-a e considere a encriptação no nível do aplicativo para campos extremamente confidenciais). Evite a exposição excessiva de dados: não armazene desnecessariamente dados de que não precisa e elimine dados confidenciais quando já não forem necessários. Quanto à secrets : nunca codifique secrets código ou configuração que vão para o controlo de origem. Use variáveis de ambiente, serviços de gestão de segredos (como HashiCorp Vault ou armazenamentos de segredos na nuvem) ou, pelo menos, armazene secrets ficheiros de configuração seguros que não estejam no repositório. Se precisar de confirmar alguma configuração, use ferramentas para verificar se secrets enviar. Alterne as chaves regularmente para que, se algo vazar, seja válido apenas por um curto período.

A plataforma de segurançaAikidopossui recursos robustos para ajudar em ambas as frentes. A sua capacidade Secrets irá analisar o seu código e configuração em busca de chaves API, palavras-passe, certificados privados e outras credenciais. Por exemplo, se alguém acidentalmente deixar uma chave AWS ou uma cadeia de conexão de base de dados num ficheiro confirmado, Aikido sinalizá-la imediatamente, potencialmente salvando-o de uma invasão da sua conta AWS. Aikido até monitorizar os seus repositórios continuamente para detectar vazamentos de segredos em tempo real. No que diz respeito à proteção de dados, a análise Aikidopode identificar o uso de criptografia fraca (como o uso de funções hash ou algoritmos de criptografia desatualizados). Ele também pode verificar certas verificações de conformidade (por exemplo, garantir que o TLS esteja habilitado em todos os terminais, analisando a infraestrutura como código ou definições de API). Ao integrar Aikido, você ganha um vigilante automatizado que grita “Ei, isso é uma chave API – remova-a!” antes mesmo que ela chegue à produção. E se a sua organização tem muitos repositórios privados ou equipas de desenvolvedores, esse tipo de verificação automatizada de segredos é essencial – como evidenciado pelo número cada vez maior de secrets no código a cada ano.

7. Utilização de componentes com vulnerabilidades conhecidas (riscos da cadeia de abastecimento)

O que é: As aplicações web modernas são construídas com base em inúmeros componentes de terceiros – frameworks, bibliotecas, pacotes, container e serviços. Utilizar componentes com vulnerabilidades conhecidas significa que a sua aplicação inclui uma dependência (ou é executada num servidor) que tem uma falha de segurança publicamente conhecida e que não foi corrigida ou atualizada. Este é essencialmente o problema da «cadeia de abastecimento»: uma vulnerabilidade numa biblioteca que utiliza pode comprometer a sua aplicação, mesmo que o seu próprio código seja perfeito. Os exemplos são abundantes: uma versão vulnerável de uma estrutura web, uma biblioteca OpenSSL desatualizada, uma ferramenta de depuração com fugas, etc. Os atacantes procuram ativamente aplicações que utilizam versões vulneráveis específicas de software para as explorar. Top 10 OWASP esse risco (anteriormente “Usando componentes com vulnerabilidades conhecidas”, agora incorporado a uma categoria mais ampla em 2021), e o setor aprendeu lições difíceis com incidentes como o Log4Shell, em que uma única falha na biblioteca teve um efeito cascata global.

Exemplo: O caso mais emblemático é, sem dúvida, o Log4Shell (CVE-2021-44228). Tratava-se de uma vulnerabilidade RCE crítica na popular biblioteca de registo Log4j (amplamente utilizada em aplicações Java). Quando foi divulgada em dezembro de 2021, ela disparou alarmes em todos os lugares, pois milhares de aplicações estavam indiretamente vulneráveis, caso incluíssem uma determinada versão do Log4j. Os invasores rapidamente começaram a explorá-la, levando a incidentes em muitas empresas. Como afirmou um relatório, “a vulnerabilidade do Log4j demonstrou como um único componente amplamente utilizado pode criar exposição em toda a organização”. Outro exemplo: o Apache Struts 2 tinha uma falha RCE conhecida (CVE-2017-5638) que levou à famosa violação da Equifax em 2017 – a Equifax não tinha atualizado a estrutura e os atacantes exploraram-na para roubar dados de 147 milhões de pessoas. Mais recentemente, em 2022-2023, vimos o Spring4Shell (CVE-2022-22965) — uma vulnerabilidade do Spring Framework que ecoou o Log4Shell (embora menos grave) — e várias vulnerabilidades de pacotes npm/PyPI que permitiam aos atacantes executar código ou roubar dados se você usasse esses pacotes. Mesmo as bibliotecas front-end não estão isentas: por exemplo, uma vulnerabilidade na biblioteca DOMPurify em 2021 poderia comprometer proteção XSS não fosse atualizada. Tudo isso ilustra que os CVEs conhecidos na sua pilha são bombas-relógio.

Impacto: O impacto depende inteiramente da vulnerabilidade específica do componente, mas pode ser tão grave quanto possível – execução remota de código, fuga de dados, contorno de autenticação, entre outros. O problema é que essas vulnerabilidades são de conhecimento público e, muitas vezes, o código de exploração está prontamente disponível, de modo que os invasores podem automatizar varreduras para encontrar qualquer servidor que não tenha sido corrigido. Um único componente não corrigido pode levar a um comprometimento em massa se for vulnerável a worms (como aconteceu com as vulnerabilidades MS Exchange ProxyShell/ProxyLogon de 2021 – não exatamente um “aplicativo web”, mas um conceito semelhante de vulnerabilidades conhecidas exploradas em massa). Para a sua aplicação, usar um componente vulnerável pode significar que um invasor não precisa encontrar um bug no seu código – ele apenas explora a biblioteca. O resultado pode ser o mesmo de outras categorias: violação de dados, invasão do servidor, etc., mas é particularmente frustrante porque uma correção pode estar disponível e simplesmente não foi aplicada.

Prevenção: Isso se resume a gerenciamento de dependências e disciplina de patching. Mantenha um inventário de todos os componentes (incluindo suas versões) usados em sua aplicação – isso é frequentemente chamado de lista de materiais de software (SBOM). Assine feeds de vulnerabilidade ou use ferramentas automatizadas para alertá-lo quando uma biblioteca que você usa tiver uma CVE conhecida. Muitos gerenciadores de pacotes possuem comandos de auditoria (por exemplo, auditoria npm, pip-audit) para identificar vulnerabilidades conhecidas em sua árvore de dependências. Mantenha suas dependências atualizadas – faça upgrade para versões corrigidas prontamente. Onde possível, use ferramentas para aplicar patches virtuais ou soluções alternativas se você não puder fazer o upgrade imediatamente. Para componentes como seu sistema operacional, servidor web ou servidor de banco de dados, aplique atualizações de segurança regularmente. Também esteja atento a pacotes maliciosos no ecossistema open-source – ocasionalmente, atacantes publicam uma biblioteca comprometida (ou sequestram uma conta de mantenedor) para que, na próxima vez que você npm install, você pode estar puxando uma atualização com backdoor. Usar fontes confiáveis e bloquear as versões das dependências (e verificar a integridade via checksums/assinaturas) pode ajudar a mitigar isso.

Aikido facilita muito o gerenciamento desse risco através de seus recursos de análise de composição de software (SCA) e análise de dependências. O scanner Dependencies (SCA) do Aikido detectará automaticamente as bibliotecas e versões open-source que seu código está usando, fará a referência cruzada com bancos de dados de vulnerabilidades e o alertará sobre quaisquer CVEs conhecidas. Por exemplo, se seu projeto estiver usando, digamos, Log4j 2.14.0 (que é vulnerável ao Log4Shell), o Aikido sinalizaria isso com detalhes sobre a CVE e até sugeriria a versão corrigida para a qual você deveria fazer o upgrade. Ele pode fazer isso diretamente em sua IDE ou pipeline de CI. Melhor ainda, o Aikido oferece sugestões de AI AutoFix – em muitos casos, ele pode abrir automaticamente um pull request para atualizar uma dependência para uma versão mais segura, ou aplicar um patch necessário. A plataforma também pode escanear imagens de Container em busca de componentes desatualizados (garantindo que suas imagens base e pacotes de sistema operacional estejam atualizados). Ao integrar o Aikido, você essencialmente terceiriza o trabalho tedioso de rastrear CVEs para um sistema automatizado que nunca dorme. Isso significa remediação mais rápida – crítica quando exploits estão frequentemente em circulação dias ou horas após o anúncio de uma vulnerabilidade. Em resumo: mantenha tudo atualizado e use ferramentas como Aikido SCA para se manter à frente dos atacantes na frente de componentes.

8. Cross-Site Request Forgery (CSRF)

O que é: Cross-Site Request Forgery é um ataque onde um site malicioso engana o navegador de um usuário para que faça requisições não intencionais à sua aplicação web. Ele explora o fato de que os navegadores incluem automaticamente credenciais (como cookies de sessão) nas requisições. Se um usuário estiver logado no seu site e, em seguida, visitar um site malicioso, esse site malicioso poderia, por exemplo, carregar uma imagem ou um formulário oculto que envia uma requisição para o seu site (o alvo) – e o navegador incluirá o cookie de sessão do usuário. Sem a defesa adequada, seu servidor pensa que o usuário fez essa requisição legitimamente e a executará. Em essência, o CSRF “sequestra” a sessão autenticada de um usuário para realizar uma ação que o usuário não pretendia. Exemplo clássico: um usuário está logado em seu banco. Ele visita a página de um atacante que possui um código oculto que emite uma requisição de transferência de fundos para o site do banco – o banco vê um cookie de sessão válido e processa a transferência. O CSRF não rouba dados diretamente; ele engana o navegador da vítima para que seja cúmplice do atacante. Muitos frameworks modernos possuem proteções CSRF integradas (geralmente via tokens), e navegadores modernos adicionaram atributos de cookie SameSite para mitigar o CSRF, mas está longe de ser erradicado. Em 2025, o CSRF “não está morto, apenas diferente” – especialmente com single-page apps e APIs usando cookies para autenticação, onde os desenvolvedores podem esquecer de implementar as proteções usuais.

Exemplo: Um exemplo real: o Reddit (2023) teve uma vulnerabilidade CSRF em uma página de configurações que permitia aos atacantes alterar silenciosamente as preferências de um usuário e até mesmo vincular a conta da vítima a uma conta de spam. Embora alternar as preferências de notificação não seja tão grave quanto transferências de dinheiro, isso mostra que o CSRF estava ativo na funcionalidade de um site importante. Outro exemplo notável envolve aplicativos de carteira de criptomoedas – atacantes usaram CSRF para alterar endereços de pagamento padrão ou iniciar pequenas transações explorando a interface web da carteira, efetivamente drenando fundos sem que o usuário percebesse. Historicamente, também houve ataques CSRF mais devastadores: o Gmail teve um CSRF em 2007 que permitiu aos atacantes alterar os endereços de encaminhamento de e-mail dos usuários (espionando e-mails), e houve o famoso Samy Worm no MySpace em 2005, que era na verdade um CSRF auto-propagável (combinado com XSS) que fez o perfil de Samy Kamkar acumular um milhão de “amigos”. Esses exemplos variam de travessuras a violações significativas, mas todos ressaltam a ideia: se você não tiver proteções CSRF, um atacante pode fazer com que seus usuários realizem ações que eles não pretendiam.

Impacto: A gravidade do CSRF depende das ações que são vulneráveis. Se apenas algumas pequenas alterações de preferência forem possíveis (como no exemplo do Reddit), o impacto é limitado (irritante, mas não catastrófico). Mas se ações críticas como transferências de dinheiro, alterações de senha ou exclusões de conta forem vulneráveis, então o CSRF é um grande problema. Considere um CSRF que altera a senha de um usuário logado para uma conhecida pelo atacante – isso é uma tomada de conta completa. Ou um CSRF em um aplicativo bancário baseado na web que emite um pagamento – isso é roubo financeiro direto. Em um contexto corporativo, um CSRF que aciona alguma mudança de estado (como alterar uma configuração de controle de acesso ou injetar dados maliciosos) pode ser um trampolim para um comprometimento mais profundo. A natureza silenciosa do CSRF – sem malware na máquina do usuário, sem sinal externo imediato – significa que tais ataques podem passar despercebidos até que seja tarde demais.

Prevenção: A boa notícia é que o CSRF é bem compreendido e existem defesas padrão:

• Tokens CSRF: Implemente tokens anti-CSRF para requisições que alteram o estado. O servidor gera um token aleatório, o define na sessão do usuário (ou como um cookie) e também o injeta em formulários ou APIs (como um campo oculto ou cabeçalho). Quando uma requisição chega, o servidor espera o token e o verifica. Uma requisição forjada por um atacante não terá o token correto, então ela é rejeitada.
• Atributo de Cookie SameSite: Defina seus cookies de sessão com SameSite=Lax ou Strict. Isso ajuda a evitar que o navegador inclua cookies em requisições cross-site (embora Lax ainda permite algumas requisições GET – que idealmente não deveriam ter efeitos colaterais). Muitos frameworks agora definem os cookies de sessão por padrão para SameSite=Lax. Apenas tenha cuidado se seu aplicativo legitimamente precisar de requisições cross-site (por exemplo, integrações de terceiros) – você pode precisar de exceções, mas isole-as, se for o caso.
• Garanta que ações que alteram o estado usem verbos HTTP apropriados (por exemplo, use POST/PUT/DELETE, não GET, para ações). Os navegadores não enviarão credenciais em POSTs cross-site se SameSite for Lax ou Strict, e é mais difícil para um atacante fazer um POST oculto do que um GET.
• Verifique os cabeçalhos Origin/Referer: Como uma camada adicional, verificar se as requisições se originam do seu domínio esperado pode detectar tentativas cross-site em alguns casos (embora não seja infalível).
• Segurança do framework: Use o middleware de proteção CSRF integrado do seu framework – quase todos os frameworks modernos possuem um.
• Não o desative durante o desenvolvimento (desenvolvedores às vezes desativam as verificações CSRF para testar APIs e depois esquecem de reativá-las).

O Aikido pode ajudar a garantir que seu aplicativo não esteja, sem que você saiba, vulnerável a CSRF. Para começar, A varredura dinâmica (DAST) do Aikido pode simular CSRF ao tentar realizar ações que alteram o estado a partir de um contexto externo e verificar se elas são bem-sucedidas. Ele relatará quaisquer ações que não possuam proteção CSRF adequada. No lado do código, a análise estática do Aikido (com sua compreensão de frameworks) pode identificar rotas que modificam dados, mas não possuem verificação de token CSRF. (Na verdade, ferramentas como Ghost Security – uma ferramenta AppSec similar – anunciam especificamente a descoberta de “endpoints que alteram o estado, mas não possuem tokens CSRF”, e o Aikido oferece capacidades comparáveis.) O Aikido também pode detectar configurações incorretas de SameSite atributos ao inspecionar os cabeçalhos Set-Cookie em suas respostas ou configurações de segurança. Ao usar o Aikido para testar seus formulários e endpoints de API, você será alertado se algum caminho crítico estiver sem defesas CSRF, para que possa corrigi-lo (geralmente adicionando o token ou as verificações de cabeçalho apropriados). Com essas medidas, você pode efetivamente eliminar o CSRF – garantindo que seu aplicativo apenas honra as requisições que realmente vêm do seu site e dos seus usuários.

9. Server-Side Request Forgery (SSRF)

O que é: SSRF é uma adição mais recente ao Top 10 OWASP (tornou-se um item do top 10 na edição de 2021) e por um bom motivo. Server-Side Request Forgery ocorre quando um aplicativo recebe uma URL ou localização de recurso de uma fonte não confiável (como entrada do usuário) e o código do lado do servidor busca essa URL sem validação adequada. Essencialmente, um invasor engana seu servidor para que ele envie uma requisição em seu nome. Isso pode ser abusado para fazer com que o servidor realize requisições a recursos internos que o invasor não consegue acessar diretamente, ou a endereços externos com as credenciais do servidor. Um cenário clássico é um aplicativo web com um recurso como “buscar o conteúdo desta URL” (para pré-visualização ou importação de dados) – um invasor fornece uma URL como http://localhost/admin ou uma URL de metadados da AWS (http://169.254.169.254) para recuperar informações internas sensíveis através do seu servidor. SSRF também pode permitir a varredura de portas da sua rede interna via seu servidor, ou até mesmo a exploração de serviços internos. Em ambientes Cloud, SSRF é particularmente perigoso porque instâncias Cloud frequentemente têm acesso a endpoints de metadados que fornecem credenciais. A violação da Capital One em 2019 foi um excelente exemplo de SSRF usado na prática (combinado com má configuração).

Exemplo: A violação da Capital One: Uma ex-engenheira da AWS explorou uma vulnerabilidade SSRF em um WAF (firewall de aplicação) mal configurado que a Capital One estava executando. Ao criar requisições a partir de um aplicativo web acessível externamente, ela conseguiu consultar o serviço de metadados da AWS do servidor, que retornou tokens de acesso da AWS. Usando esses tokens, ela então acessou dados sensíveis (buckets S3 com informações de clientes) – resultando em mais de 100 milhões de registros roubados. Em resumo, SSRF foi o ponto de entrada inicial que contornou as barreiras de rede externas ao alavancar os próprios privilégios do servidor. Outro exemplo: Em 2022, pesquisadores de segurança descobriram que um SSRF em uma ferramenta DevOps popular permitiu que eles alcançassem endpoints de API internos que não estavam expostos de outra forma, potencialmente permitindo ações de administrador. Também vimos bugs de SSRF em funcionalidades de processamento de imagem ou geração de PDF (onde o servidor busca uma URL de entrada) que os invasores transformaram em varredores de portas ou usaram para atingir consoles de administração de banco de dados internos. Mais um caso: alguns serviços Cloud tinham SSRF em seus webhooks que permitiam aos invasores acionar requisições para endpoints HTTP internos, obtendo acesso a coisas como Redis ou dashboards internos.

Impacto: À primeira vista, o SSRF trata de fazer requisições, o que pode parecer limitado. Mas pode ter um impacto crítico:

• Acesso à rede interna: Se o seu servidor puder alcançar hosts internos (por exemplo, na mesma VPC ou data center), um SSRF pode potencialmente se comunicar com serviços internos que não estão expostos publicamente. Isso pode levar à leitura de dados sensíveis (como contatar uma API HTTP interna que retorna informações do cliente) ou até mesmo à emissão de comandos privilegiados se uma interface de administração interna não tiver auth (já que se presumia que apenas chamadas internas a alcançariam).
• Vazamento de metadados da Cloud: Em provedores de Cloud (AWS, GCP, Azure), o SSRF é frequentemente usado para obter credenciais do serviço de metadados da instância. Essas credenciais podem permitir um comprometimento adicional dos recursos da Cloud (como no caso da Capital One).
• Bypass de restrições baseadas em IP: Se você restringir alguma funcionalidade a, digamos, requisições de “localhost” ou de certos IPs, um SSRF pode contornar isso fazendo a requisição a partir do próprio servidor local.
• Potencial de worm: Em alguns casos, o SSRF pode ser um ponto de pivô para explorações adicionais – por exemplo, um SSRF para um serviço interno que possui um RCE conhecido pode resultar em execução remota de código real na rede interna.
  Dada a nota do Top 10 OWASP, os problemas de SSRF estão de fato em ascensão em aplicativos modernos devido às complexidades de microsserviços e Cloud, e podem ser bastante severos.

Prevenção: Prevenir o SSRF significa principalmente validar e higienizar quaisquer URLs fornecidas pelo usuário ou requisições de recursos remotos. Se seu aplicativo precisar buscar uma URL fornecida por um usuário (ou um endereço), implemente uma allowlist estrita: por exemplo, permita apenas URLs de um conjunto de domínios em que você confia (e force isso via DNS lookup, etc., para evitar truques). Nunca permita que a entrada bruta do usuário controle diretamente o destino das buscas do lado do servidor. Você também pode implementar proteções em nível de rede: por exemplo, desabilitar a capacidade do seu servidor de alcançar endereços internos se ele não precisar. Alguns provedores de Cloud permitem que você desative ou restrinja o acesso ao serviço de metadados (a AWS possui o IMDSv2 que mitiga as requisições GET simples). Além disso, o código deve verificar o esquema da URL – desautorize file:// URIs ou outros esquemas locais, e potencialmente desautorize literais de IP ou endereços link-local. Use bibliotecas ou patches que realizem proteção contra SSRF, se disponíveis (por exemplo, algumas bibliotecas de cliente HTTP permitem restringir quais hosts podem ser contatados). Essencialmente, trate URLs fornecidas externamente como entrada perigosa – porque elas são.

As ferramentas de scanning da Aikido podem ajudar a identificar riscos de SSRF no seu código. Por exemplo, a análise estática da Aikido pode detectar o uso de funções ou bibliotecas que fazem requisições HTTP (como requests.get() em Python, HttpClient em Java, etc.) onde a URL é derivada da entrada do usuário. Pode então sinalizar isso como um SSRF potencial se não houver filtragem. A Aikido também pode notar se seu código tenta buscar coisas de URLs sem validação, e pode sugerir a adição de verificações de allowlist. No lado dinâmico, As ferramentas DAST e de pentest da Aikido podem tentar payloads comuns de SSRF (como fornecer http://169.254.169.254 como entrada para qualquer funcionalidade de busca de URL) para ver se conseguem enganar o servidor para responder com conteúdo interno. Se um vetor de SSRF for encontrado, a Aikido o reportará junto com as evidências. Com este feedback, você pode então implementar validação adequada ou restringir o acesso à rede. Os recursos de scanning de Cloud da Aikido também podem avisá-lo se suas instâncias tiverem configurações de rede excessivamente permissivas (por exemplo, se seu servidor web puder sair para a internet ou rede interna quando não deveria). Ao combinar análise de código e testes, você pode detectar fraquezas de SSRF precocemente – antes que um atacante use seu aplicativo como proxy.

10. Desserialização Insegura

O que é: A desserialização insegura é uma vulnerabilidade mais especializada, mas incrivelmente perigosa quando existe. Ela surge quando um aplicativo desserializa dados de uma fonte não confiável sem validação adequada – significando que ele pega alguns dados binários ou estruturados (como objetos, ou JSON/XML, ou blobs binários) do cliente e reconstrói um objeto na memória. Certos formatos de serialização (especialmente em linguagens como Java, .NET, Python, PHP) podem ser abusados para executar código durante o processo de desserialização. Atacantes criam objetos serializados maliciosos (frequentemente chamados de “gadget chains”) que, quando o servidor os desserializa, acionam comandos ou comportamentos que o atacante escolhe. Isso pode levar à execução remota de código ou manipulação de lógica no servidor, sem nem mesmo precisar de uma falha de injeção normal. Vulnerabilidades de desserialização insegura são essencialmente bombas lógicas escondidas em dados. Elas foram destacadas no Top 10 OWASP 2017 e permanecem relevantes, embora o Top 10 de 2021 tenha ampliado para “Falhas de Integridade de Software e Dados”. Se um aplicativo aceita qualquer tipo de objetos serializados (como objetos Java Serializable objects, .NET ViewState, ou até mesmo certos JSON com informações de tipo de classe) de usuários, ele pode estar em risco.

Exemplo: Um exemplo recente que está causando impacto é CVE-2025-55182 em React Server Components (divulgado em dez de 2025). Esta foi uma RCE crítica que se revelou causada por desserialização insegura no protocolo React Server Components. Essencialmente, um invasor poderia enviar um payload HTTP malformado que o lado do servidor React desserializaria incorretamente, permitindo a execução de código arbitrário. Tinha um CVSS 10 e afetou um grande número de aplicações (já que o React é tão difundido). Isso mostra que mesmo frameworks de ponta não estão imunes a problemas de desserialização. Outro exemplo clássico: o exploit de 2016 do Java Commons Collections – uma desserialização insegura em muitos aplicativos Java (através de uma biblioteca) permitiu que invasores enviassem um objeto serializado que, após a desserialização, executaria comandos no servidor. Isso foi amplamente explorado em produtos como Jenkins, WebLogic, etc. No .NET, houve a vulnerabilidade de desserialização do ViewState (CVE-2017-8759) e outras onde dados não sanitizados em um view state levaram a RCE. Aplicativos PHP tiveram problemas quando unserialize() é chamado em entrada de usuário. Mesmo JavaScript (Node.js) teve um notório no serialize-javascript pacote. Assim, de sistemas corporativos a frameworks modernos, a desserialização insegura surge – muitas vezes com resultados graves.

Impacto: A desserialização insegura é frequentemente um caminho direto para a execução remota de código (RCE). Isso é o pior que pode acontecer – o invasor pode executar código arbitrário em seu servidor, potencialmente assumindo o controle total dele. Mesmo que não seja uma RCE completa, falhas de desserialização podem ser usadas para manipular a lógica (por exemplo, alterando estruturas de dados para conceder a si mesmo privilégios mais altos em dados de objetos). Mas, tipicamente, o impacto é crítico: se um invasor conseguir explorá-la, ele frequentemente pode instalar um webshell, criar um usuário backdoor ou aprofundar-se na rede. O perigo é amplificado pelo fato de que os exploits de desserialização muitas vezes não exigem autenticação (se o aplicativo estiver desserializando dados antes da autenticação) e podem ser feitos com uma única requisição. É uma forma furtiva de entrada – sem consultas SQL suspeitas ou scripts cross-site, apenas um blob de dados aparentemente inócuo que detona seu aplicativo por dentro.

Prevenção: A melhor maneira de evitar a desserialização insegura é nunca desserializar dados não confiáveis. Se você não precisa absolutamente aceitar objetos serializados de usuários, não o faça. Use formatos de dados mais seguros (JSON, por exemplo, sem metadados de tipo de classe que poderiam invocar construtores arbitrários). Se você precisar serializar/desserializar, considere implementar verificações de integridade: por exemplo, assine os dados serializados ou inclua um MAC, para que a adulteração seja detectável. Alguns frameworks permitem restringir quais classes podem ser desserializadas (allow-listing de classes). Isso pode impedir que cadeias de gadgets arbitrárias funcionem. Mantenha as bibliotecas atualizadas, pois muitas falhas de desserialização são corrigidas ao restringir o código que é executado durante a construção do objeto. A OWASP também sugere isolar o processo de desserialização – talvez executando-o em um ambiente de baixo privilégio ou em sandbox, para que, se um exploit for acionado, ele tenha um impacto mínimo. Em geral, trate os dados serializados como potencialmente hostis. Além disso, esteja ciente da serialização oculta, como em comunicações entre serviços ou caches.

A inteligência de vulnerabilidades e o scanning da Aikido podem ajudar a detectar esses problemas. No lado da análise estática, a Aikido pode sinalizar usos de funções ou padrões perigosos – por exemplo, o uso de ObjectInputStream.readObject() em Java, ou do PHP unserialize() em dados de usuário, ou bibliotecas de desserialização inseguras conhecidas por serem exploráveis. Ele avisará que “ei, você está desserializando algo aqui – isso é seguro?”. A análise de dependências da Aikido também entra em jogo: ela pode alertá-lo se você estiver usando uma versão de biblioteca conhecida por ter uma vulnerabilidade de desserialização (por exemplo, uma versão desatualizada de uma biblioteca de serialização comum). Se um CVE importante como CVE-2025-55182 (o do React) surgir, os feeds de Threat Intelligence da Aikido (como Aikido Intel) destacariam quais de seus projetos podem ser afetados e precisam de um patch. Em termos de teste, este é mais difícil para scanners dinâmicos, mas o Aikido Attack pode tentar payloads de exploit conhecidos se seu aplicativo estiver usando um framework comum conhecido por um bug de desserialização. Em última análise, a mitigação frequentemente requer mudanças de código ou atualizações de biblioteca, e o papel da Aikido é alertá-lo rapidamente sobre o risco. Ao detectar a desserialização insegura durante o desenvolvimento ou scanning, você pode refatorar para usar formatos de dados seguros ou atualizar para versões corrigidas antes de implantar uma bomba-relógio.

Construindo uma Postura Segura para Aplicações Web

Como vimos, as aplicações web hoje enfrentam uma infinidade de vulnerabilidades – desde falhas de injeção que podem vazar seu banco de dados, a lapsos de lógica que permitem que invasores contornem sua autorização, a vazamentos de Secrets e riscos de dependência que vêm das ferramentas nas quais confiamos. Pode parecer assustador, mas o fio condutor comum é a conscientização e a defesa proativa. Ao entender essas principais vulnerabilidades, você já está um passo à frente na mitigação delas.

Alguns pontos-chave para uma postura de segurança robusta de aplicações web:

• Desloque a segurança para a esquerda (Shift Left): Detecte problemas cedo no desenvolvimento. Integre ferramentas SAST/SCA (como Aikido) em seu pipeline de CI e IDE, para que as vulnerabilidades sejam sinalizadas e corrigidas antes que o código seja mesclado. É muito mais fácil corrigir uma consulta SQL insegura ou adicionar uma verificação de autenticação durante a codificação do que correr para resolver após uma violação.
• Defesas em camadas: Use múltiplas camadas de controles de segurança. Por exemplo, para prevenir injeção e XSS, combine práticas de codificação seguras com bibliotecas de segurança, e também execute um firewall de aplicação (WAF) para proteção adicional. Para autenticação, imponha MFA e use monitoramento para detectar logins suspeitos. Defesa em profundidade significa que mesmo que uma camada falhe, outras detectam o problema.
• Mantenha-se atualizado: Mantenha dependências e servidores corrigidos (patched). Considere habilitar atualizações automatizadas para componentes críticos quando viável. Aproveite feeds ou plataformas de vulnerabilidades (Aikido, Dependabot, etc.) para saber quando você tem algo vulnerável em sua stack. Quanto mais rápido você corrige problemas conhecidos, menos provável será pego por campanhas de mass-exploit.
• Gerenciamento de Secrets e menor privilégio: Trate as credenciais como as joias da coroa. Use vaults ou configurações de ambiente para Secrets, rotacione-os regularmente e dê a cada serviço o acesso mínimo de que ele precisa. Dessa forma, mesmo que uma chave seja comprometida, isso limita o raio de impacto.
• Segurança por design: Incorpore modelagem de ameaças (threat modeling) e princípios de design seguro desde o início. Para novos recursos, considere como eles poderiam ser abusados e incorpore as verificações necessárias (por exemplo, garanta que um novo recurso de upload de arquivos valide tipos e tamanhos de arquivos para prevenir desserialização ou problemas de DoS, garanta que um novo endpoint de API verifique as funções do usuário para prevenir falhas de controle de acesso, etc.).
• Eduque e automatize: Mantenha a equipe de desenvolvimento informada sobre armadilhas comuns (como as do Top 10 OWASP). Use scanners e testes automatizados como uma rede de segurança, mas também promova uma cultura onde os desenvolvedores pensem sobre o impacto da segurança. Um pouco de conscientização ajuda muito a evitar, por exemplo, a tentação de desabilitar tokens CSRF “apenas para testar” ou de copiar e colar código do StackOverflow sem considerar a segurança.

Ao focar nessas práticas essenciais, você pode reduzir drasticamente o perfil de risco da sua aplicação. Muitos ataques são bem-sucedidos não por serem ultrassofisticados, mas porque a higiene de segurança básica foi negligenciada. Corrija essas lacunas, e os invasores procurarão alvos mais fáceis.

Conclusão

Construir aplicações web que possam resistir às ameaças atuais está totalmente ao alcance das equipes de desenvolvimento – especialmente com as ferramentas certas em seu arsenal. Analisamos as principais vulnerabilidades web que afetam as aplicações e vimos como elas se relacionam com incidentes reais. O denominador comum é que a conscientização e a detecção precoce fazem toda a diferença. Quando você sabe o que procurar – seja uma entrada não sanitizada, uma verificação de acesso ausente ou uma biblioteca desatualizada – você pode abordá-lo proativamente em vez de reativamente.

Como desenvolvedor ou engenheiro DevSecOps, você não precisa enfrentar isso sozinho. Soluções AppSec modernas como Aikido Security são projetadas para se encaixar perfeitamente no seu fluxo de trabalho e detectar esses problemas rapidamente. Imagine ter um especialista em segurança automatizado revisando cada commit: sinalizando aquele bug XSS sorrateiro, capturando a chave AWS antes que ela saia do seu laptop, apontando que você está usando uma versão de uma biblioteca com uma CVE crítica e até mesmo sugerindo ou aplicando correções. É isso que Aikido oferece – varredura completa para código, dependências, configuração e muito mais, feito para desenvolvedores. É como ter o Top 10 OWASP e o último banco de dados de CVEs monitorando você, sem te atrasar.

Próximos passos: Não espere por uma auditoria ou (pior) uma violação para encontrar essas vulnerabilidades. Você pode começar executando uma varredura de segurança em sua base de código para ver sua situação. Configure regras de linting para segurança, adicione verificação de dependências e ative 2FA em todos os lugares. Se você está interessado em uma plataforma focada no desenvolvedor que faz tudo isso e muito mais, considere experimentar o Aikido – ele oferece varredura de código, SAST, detecção de segredos, varreduras de IaC e Container, além de correções assistidas por IA em uma interface unificada. Na verdade, o Aikido pode mapear automaticamente o status do seu projeto em relação à cobertura do Top 10 OWASP e ajudar você a fechar as lacunas.

No final, o objetivo é integrar a segurança ao processo de desenvolvimento. Ao focar nessas principais vulnerabilidades, escrever código seguro e usar ferramentas para automatizar o trabalho pesado, você reduzirá significativamente o risco para suas aplicações web. Os dados dos seus usuários permanecem seguros, sua aplicação permanece ativa e você pode dormir um pouco mais tranquilo à noite (assim como os 42% das equipes que ficam acordadas preocupadas com a segurança de Container e aplicações, mencionados anteriormente!).

Você também pode gostar:

• Principais Vulnerabilidades de segurança na nuvem
• Principais Vulnerabilidades de segurança Kubernetes
• Principais Vulnerabilidades de segurança de contêineres Docker