Olá, pessoal do MundiX! Sou Denis Makrushin, Diretor de Produtos de Desenvolvimento Seguro da SourceCraft na Yandex Infrastructure. Meu ranking anual favorito é o Top 10 web hacking techniques, preparado pela comunidade de pesquisadores por iniciativa da PortSwigger. O ranking apresenta materiais que compartilham inovações na busca e exploração de vulnerabilidades. Hoje, quero falar sobre as pesquisas que achei mais interessantes, pois mostram não apenas vulnerabilidades individuais, mas categorias inteiras de problemas e novos métodos de ataque.
Interpretação Inconsistente: Como a Normalização Incorreta de Dados e a Diferença em Seu Processamento Levam a Vulnerabilidades
A pesquisa com o nome complexo "Diferencial de Parsers" traz uma ideia simples: se um sistema tem dois ou mais manipuladores de dados (JSON, YAML ou HTTP) que analisam os mesmos dados de maneiras diferentes, espere problemas. O autor mostra claramente como o aumento da complexidade do sistema e o número de conexões nele levam ao surgimento de novos problemas, muitas vezes não óbvios. Não basta verificar a segurança de cada componente do sistema separadamente - é preciso garantir que a combinação desses componentes não crie vulnerabilidades.
O autor apresenta vários cenários de ataque:
- Execução Remota de Código no CouchDB. Este sistema de banco de dados é escrito em Erlang e usa JavaScript para validar documentos. Ao receber JSON com parâmetros duplicados (por exemplo, dois parâmetros roles), a biblioteca Erlang os transformava em um array e usava o primeiro valor encontrado. E o mecanismo JavaScript pegava apenas o último valor desse array. Um invasor passou dois valores do parâmetro roles para o banco de dados. O mecanismo JS viu um valor seguro e o passou adiante, e o Erlang viu o primeiro valor (_admin) e criou uma conta privilegiada. Este cenário lembra muito a classe de vulnerabilidades HTTP Parameter Pollution, certo?
- Escrita Arbitrária de Arquivos. A diferença entre os parsers Ruby e Go permitiu que um invasor contornasse o filtro de parâmetros perigosos em arquivos YAML. A parte Ruby não filtrava o parâmetro perigoso parent, mas o parser Go o via. O invasor conseguiu passar o parâmetro proibido pelos filtros e conseguiu gravar arquivos arbitrários no sistema.
Outro exemplo de uma categoria semelhante de problemas são as vulnerabilidades que surgem durante a normalização Unicode. Diferentes elementos da cadeia de tráfego da web (navegador, proxy, CDN, WAF, aplicativo, banco de dados) podem decodificar e normalizar strings Unicode de maneiras diferentes. Há algo em comum com o cenário de ataque anterior: a verificação de caracteres perigosos funciona em uma representação da string, e em outro lugar outra forma dessa string é processada. Devido às diferenças entre as formas de normalização, o registro e caracteres semelhantes, um invasor pode mascarar a entrada para contornar filtros e regras.
No final de cada seção, darei pequenas recomendações sobre como evitar riscos ou impedir o tipo de ataque descrito. Os conselhos são baseados em minha experiência pessoal e nas ideias que os autores das pesquisas descrevem.
Como se proteger
- Use o princípio "Eu passo o que entendo". Para excluir o "diferencial de parsers" no nível da arquitetura do projeto, você não deve enviar dados brutos de um parser para outro. É necessário fazer um inventário de todos os parsers que são usados no sistema: usando SCA, faça uma lista das bibliotecas envolvidas na análise e, por meio de SAST, determine o caminho dos dados de entrada "brutos".
- Para se proteger contra vulnerabilidades relacionadas à normalização Unicode, você precisa converter a string para uma forma unificada antes de usá-la na lógica de negócios e certificar-se de que a mesma forma de normalização seja usada em todos os componentes. Além disso, você deve pedir ao seu colega de appsec para estudar esses ataques e configurar o DAST.
Características dos Protocolos: Execução de Solicitações Arbitrárias em HTTP/2 e Nova Técnica SSRF
Se o proxy HTTP estiver configurado incorretamente, um invasor pode enviar solicitações CONNECT através dele para hosts e portas arbitrários. O método CONNECT foi projetado para criar um túnel TCP através de um proxy. O proxy tenta estabelecer uma conexão com o endereço especificado e retorna o resultado: a conexão foi estabelecida, rejeitada ou ocorreu um tempo limite. Ao analisar essas respostas, um invasor pode determinar quais hosts e portas estão disponíveis. Se o proxy permitir o método CONNECT para endereços internos ou não restringir a lista de destinos permitidos, ele poderá ser usado para escanear serviços internos e realizar reconhecimento de rede.
Ao rastrear as respostas para cada fluxo, um invasor pode mapear as portas abertas na rede interna.
Esse tipo de ataque provavelmente observaremos por muito tempo: eles exploram problemas que não são fáceis de corrigir. Eles estão relacionados às características dos protocolos fundamentais nos quais a comunicação das aplicações web modernas se baseia.
Os autores da pesquisa "Nova Técnica SSRF" inventaram uma nova maneira de explorar SSRF: um ataque Blind Server-Side Request Forgery, no qual o aplicativo de destino faz uma solicitação, mas não retorna o corpo da resposta, pode ser transformado em SSRF com vazamento do corpo completo da resposta.
Os pesquisadores notaram um comportamento incomum do manipulador de redirecionamento: um aplicativo que faz uma solicitação por URL e processa a resposta como JSON, com vários redirecionamentos, falhou com um erro JSON inválido, e com um grande número deles, emitiu outro erro (Exceção de Rede).
Então, eles descobriram outra anomalia: se a resposta final com o código HTTP 500 fosse retornada ao aplicativo, ele de repente retornava o corpo completo da resposta HTTP.
Os pesquisadores conseguiram tornar esse comportamento controlável e inventaram uma técnica que permite criar uma cadeia de redirecionamentos, como resultado da qual o aplicativo emite todos os resultados desses redirecionamentos junto com os segredos no corpo da resposta.
Como se proteger
- Para o problema com solicitações CONNECT, você pode preparar uma regra para seu analisador estático ou scanner IaC, que ajudará a encontrar configurações vulneráveis de servidores proxy. Por exemplo, você deve procurar configurações no arquivo de configuração que incluem o modo proxy ou tunelamento sem restrições.
- Para se proteger contra a técnica SSRF, usando SAST, você pode encontrar funções de redirecionamento no código, em cujo valor os dados do usuário são usados.
Canais de Vazamento no Chromium: Descobrindo Onde e Por Que o Navegador Foi
Nas pesquisas a seguir, fiquei interessado em como o cache e artefatos de rede imperceptíveis do navegador podem se tornar um canal de vazamento de dados. Esses ataques são mais difíceis de detectar e, portanto, mais difíceis de prevenir ou interromper.
O primeiro ataque é bastante difícil de implementar, mas conceitualmente interessante. Um invasor pode usar indicadores de tempo para entender quais recursos o navegador da vítima acessou. Um script na página do invasor preenche propositadamente o pool de conexões de rede no navegador Chromium, então, neste pool, provoca o navegador a fazer uma solicitação e, com base no sinal de qual solicitação recebeu a conexão mais cedo, faz uma conclusão. Por exemplo, uma conclusão sobre os privilégios da vítima em um determinado recurso. Repetindo as medições, você pode até restaurar a string no URL, por exemplo,
Outra pesquisa do ranking mostra um canal de vazamento no navegador Chromium, mas já usando o cabeçalho HTTP ETag (Entity Tag). Este cabeçalho é retornado pelo servidor na resposta como um identificador da versão do recurso (por exemplo, página, arquivo, JSON, etc.). Sua principal tarefa é o cache: o navegador pode perguntar na próxima vez: "Eu já tenho essa versão do recurso, ela não mudou?" - e não baixar o corpo da resposta novamente.
Um invasor atrai o navegador da vítima para seu recurso com um script. O script envia o navegador para o recurso desejado https://target.site/?query=<secret_string_which_can_be_on_the_page>. O navegador recebe a resposta e salva o ETag. Então o script muda sua solicitação, o que leva à mudança do ETag. Ao iterar sobre essas solicitações e rastrear os fatos da mudança do ETag, o invasor encontra um canal para obter segredos.
Como se proteger
- Não armazene segredos e dados confidenciais em URLs e, especialmente, em subdomínios. Não retorne ETag para páginas com dados valiosos.
Frameworks e Abstrações com Comportamento Complexo: Cache Vulnerável Next.js e Vazamentos via ORM
As pesquisas desta seção mostram uma tendência importante: as vulnerabilidades estão aparecendo cada vez mais não no código do aplicativo, mas nos mecanismos ao seu redor, por exemplo, em frameworks, cache, otimização.
Uma variante não trivial de um problema bem pesquisado de envenenamento de cache da web foi descoberta no Next.js. Os autores da pesquisa viram que no sistema de roteamento deste framework, a mesma página tem duas formas de resposta: na forma de HTML normal e em um formato JSON especial.
O problema é que, sob certas condições, um invasor pode enviar uma solicitação especialmente formada que faz com que o Next.js confunda os modos e armazene em cache o que não deve ser salvo. Como a gravação ocorre no cache embutido do próprio framework, o ataque funciona mesmo sem componentes CDN.
Como se proteger
- A vulnerabilidade é descrita para Next.js v13.5.1–14.2.9, portanto, você deve configurar seu SCA para detectar essas versões.
Outra pesquisa está relacionada à complexidade das abstrações ORM. Object-Relational Mapping, mapeamento objeto-relacional, é uma camada entre o código e o banco de dados. Com sua ajuda, os desenvolvedores trabalham com registros no banco de dados como objetos comuns no código, sem escrever uma única linha de SQL.
Às vezes, os desenvolvedores dão ao usuário um filtro complexo ou um sistema de pesquisa flexível, mas, ao mesmo tempo, permitem que esse sistema controle as expressões de filtragem ORM. Um invasor pode forçar o sistema a filtrar ou pesquisar dados por campos confidenciais e, como resultado, extrair informações valiosas.
A ideia principal desta pesquisa: você não pode simplesmente anexar filtros ao ORM - você precisa permitir explicitamente apenas campos seguros, controlar o acesso às relações e não permitir a filtragem por atributos secretos.
Como se proteger
- Usando SAST, encontre todos os locais sensíveis no código onde a entrada do usuário cai em objetos ORM sem validação estrita.
Injeções e Execução de Código: Técnicas SOAPwn e SSTI
As pesquisas a seguir me interessaram pela ideia que as une: os erros do aplicativo podem se tornar uma ferramenta de ataque. Desenvolvedores e administradores consideram um erro um resultado malsucedido da solicitação, e o invasor vê nele um sinal e uma oportunidade. Um invasor pode tentar obter acesso ao servidor ou até mesmo controlá-lo através das respostas.
A pesquisa SOAPwn conta como as classes proxy para SOAP se comportam no .NET Framework, por exemplo, SoapHttpClientProtocol. Eles devem enviar mensagens XML via HTTP, mas devido a um erro na conversão de tipos, podem ser enganados e redirecionados para outro manipulador de URL. Assim, se o aplicativo permitir que um invasor afete o URL do proxy SOAP diretamente por meio de uma configuração (ou parâmetro) ou indiretamente por meio de importação dinâmica, uma vulnerabilidade surge. Em vez de enviar pela rede, o proxy pode começar a escrever o corpo da solicitação SOAP em um arquivo ou no caminho especificado.
Exemplo de vazamento via API: ao solicitar um artigo, o servidor, por engano, retorna dados secretos da conta relacionada
A pesquisa Successful Errors mostra como os erros podem ser usados no processo de exploração de vulnerabilidades Blind-SSTI. Server-Side Template Injection permite que um invasor insira código malicioso em modelos que são interpretados e executados no lado do servidor. Com SSTI cego, um invasor pode executar comandos arbitrários no servidor, obter acesso a dados valiosos e, às vezes, ao próprio servidor, mas, ao mesmo tempo, o invasor não vê o resultado da injeção. O autor da pesquisa conseguiu transformar erros do servidor em um canal de comunicação e formalizou duas técnicas:
- Error-Based, na qual o aplicativo mostra texto de erro detalhado. Por exemplo, stack trace ou mensagem de exceção.
- Boolean Error-Based Blind, na qual é possível determinar o fato da presença ou ausência de um erro. Por exemplo, outro status de erro, outra página, outro modelo de resposta.
No primeiro caso, um invasor pode provocar deliberadamente um erro que conterá um fragmento do valor calculado em sua mensagem. Então, o invasor vê, por exemplo, strings ou números no erro e obtém a capacidade de controlar o ataque com base nesse feedback.
No segundo caso, o autor propõe construir expressões do tipo "se a condição for verdadeira, então chamamos um erro" e "se a condição for falsa, então não há erro". Assim, o invasor tem a oportunidade de testar suas hipóteses.
Como se proteger
- Ao usar SSTI ou .NET Framework, você deve estudar os detalhes dessas pesquisas e pedir ao seu LLM com base nesses materiais para gerar assinaturas para um analisador estático.
Pesquisas Promissoras da Lista de Candidatos
Essas pesquisas não foram incluídas no ranking principal, mas achei-as interessantes e dignas de atenção. O objeto de ataque nelas são camadas fundamentais: protocolos nos quais uma parte significativa da comunicação entre os componentes da rede é mantida, agentes de IA, componentes vulneráveis para descompactação de dados.
Injeções de Prompt em Agentes de IA para Geração ou Verificação da Qualidade do Código A capacidade de inserir instruções maliciosas no texto de commits, tickets ou pull requests pode forçar o agente a executar comandos privilegiados nos processos de compilação de código. O cenário de ataque é fácil de implementar, e a superfície de ataque está crescendo rapidamente junto com o número de utilitários em CI/CD. Em 2026, muitos incidentes no GitHub estarão relacionados a este vetor.
Como se proteger
- Verifique quaisquer dados de entrada de tickets ou PRs antes de passá-los para o contexto do prompt.
Retorno de Ataques Zip Slip
Não apenas novas variantes de uma vulnerabilidade conhecida associada à descompactação de arquivos estão aparecendo, mas também novas maneiras de contornar a proteção contra essa categoria de problemas. A pesquisa mostra que a verificação prévia do arquivo por si só é insuficiente: um arquivo .zip especialmente preparado pode parecer seguro para o mecanismo de validação, mas, ao descompactar pelo mesmo aplicativo, ser interpretado de forma diferente e ainda levar a sair do diretório no qual a descompactação é realizada. A novidade da pesquisa reside na exploração da divergência entre como diferentes parsers ou diferentes APIs leem o mesmo arquivo.
Isso serve como um lembrete de que velhos problemas estão retornando em novos contextos.
Como se proteger
- Ao implementar funções de descompactação de arquivos, é necessário implementar uma verificação e garantir que o caminho canônico de cada arquivo extraído esteja estritamente dentro do diretório de destino. Aqui, o analisador estático ajudará novamente.
Vulnerabilidade Fundamental do Protocolo HTTP/1.1
Em HTTP/1.1, as solicitações são simplesmente coladas umas às outras em uma única conexão de rede. Se diferentes servidores (front-end e back-end) interpretarem o comprimento da mensagem de maneiras diferentes, um invasor pode "cortar" parte de sua solicitação e substituí-la no início da solicitação do próximo usuário.
Como se proteger
- Mude para HTTP/2 na rede interna, pois este é um protocolo com uma clara separação de mensagens.
A tendência geral que pode ser vista por trás de todas essas pesquisas: os ataques estão se movendo dos próprios aplicativos para sua infraestrutura e protocolos.
Todas as pesquisas consideradas mostram uma mudança importante: os ataques modernos surgem cada vez mais não por causa de um único erro no código, mas por causa de uma incompatibilidade de suposições entre os componentes do sistema. Protocolos, proxies, caches, frameworks e ferramentas de automação começam a se comportar de maneira diferente em situações de fronteira, e é nessas diferenças que novas técnicas de exploração são construídas. Para os desenvolvedores, isso significa que a segurança não pode mais ser considerada apenas no nível de funções ou bibliotecas individuais: é importante entender como os dados afetam todo o sistema como um todo. A boa notícia é que muitos desses problemas ainda podem ser detectados na fase de desenvolvimento usando ferramentas clássicas como analisadores de código estático. O principal é saber o que e onde exatamente você precisa procurar. Portanto, quanto mais cedo a equipe de desenvolvimento se familiarizar com novas pesquisas e acompanhar o desenvolvimento de técnicas de ataque, menores serão as chances de que esses bugs não triviais apareçam na produção.
