O que é contaminação de parâmetros HTTP e por que representa um risco real?

Quando falamos sobre segurança de aplicações web, muitas pessoas pensam apenas em... Injeção de SQL, XSS ou falhas de autenticaçãoNo entanto, há anos existe uma técnica bastante silenciosa que continua passando despercebida em muitas auditorias: a contaminação ou poluição de parâmetros HTTP, conhecida como Poluição de Parâmetros HTTP (HPP) Contaminação de parâmetros HTTP.

Esse tipo de vulnerabilidade explora como diferentes tecnologias e frameworks de servidor gerenciam parâmetros duplicados na mesma requisição HTTPSe a aplicação não estiver preparada para isso, um atacante pode alterar a lógica interna, contornar validações, enganar firewalls de aplicações web (WAFs) e até mesmo assumir o controle de funcionalidades críticas, como autenticação ou gerenciamento de permissões.

Conceito de parâmetros HTTP e precedência

Em praticamente todos os sites modernos, os usuários enviam dados via Parâmetros HTTP na URL ou no corpo da requisiçãoEsses parâmetros permitem que o navegador passe informações para o aplicativo: pesquisas, dados de formulários, opções de pesquisa, comentários, credenciais de login, etc.

Em uma requisição GET típica, esses dados trafegam no string de consulta (tudo o que vem depois do sinal ? na URL)Os pares chave/valor são separados pelo símbolo de e comercial (&). Em uma requisição POST, eles podem estar no corpo da requisição, mas a lógica da aplicação no servidor geralmente os trata de maneira muito semelhante: chaves com um ou mais valores associados.

Muitas linguagens de programação e frameworks fornecem métodos para obter ambos um único valor de um parâmetro como a lista completa de valores, caso esse parâmetro apareça repetidamente. Isso é comum, por exemplo, com caixas de seleção que permitem seleção múltipla, onde o mesmo nome de parâmetro aparece várias vezes.

O problema surge quando o desenvolvedor assume que Haverá apenas um valor por parâmetro. e utiliza funções que retornam um único valor, enquanto o navegador (ou o atacante) envia múltiplos valores com o mesmo nome. Neste ponto, entra em jogo um conceito fundamental: precedência de valores.

Dependendo da linguagem, da estrutura e do servidor web, múltiplas ocorrências do mesmo parâmetro podem resultar em diversos comportamentos: que o primeiro valor recebidoque ele pega o último valor ou que é gerado uma combinação de todos (por exemplo, concatenados com vírgulas)Não existe um padrão único, portanto cada conjunto de tecnologias pode se comportar de maneira diferente, o que abre caminho para situações muito perigosas.

O fato de uma função retornar apenas um valor não é uma vulnerabilidade em si, mas quando há Parâmetros duplicados e o desenvolvedor desconhece o problema. Dependendo de como essa precedência funciona, o aplicativo pode obter um valor inesperado. Esse comportamento anômalo é exatamente o que as técnicas exploram. Poluição de parâmetros HTTP.

O que é Poluição de Parâmetros HTTP (HPP)?

A poluição de parâmetros HTTP é uma técnica que consiste em injetar parâmetros adicionais ou delimitadores de string de consulta (codificado) dentro de outros parâmetros existentes. Quando esse parâmetro injetado é decodificado e reutilizado para gerar uma nova URL ou construir outra solicitação, o aplicativo Acaba por incorporar parâmetros adicionais que o desenvolvedor não esperava..

Em outras palavras, o HPP explora a forma como a aplicação Ele reconstrói URLs, processa formulários e lida com parâmetros repetidos.Se a entrada não for validada corretamente, um atacante pode forçar o aplicativo a interpretar valores diferentes dos esperados ou a incluir parâmetros adicionais em links, formulários e redirecionamentos.

As técnicas HPP foram introduzidas publicamente por Stefano Di Paola e Luca Carettoni na conferência OWASP AppSec 2009. Desde então, eles têm sido documentados. muitos cenários de ataqueMas, mesmo hoje, elas não têm a mesma visibilidade que outras vulnerabilidades mais conhecidas, nem são totalmente cobertas por todas as ferramentas automatizadas.

O impacto de um ataque de poluição de parâmetros HTTP depende em grande parte de lógica particular da aplicaçãodo framework e do servidor web. Em alguns casos, as consequências são menores (erros de apresentação, falhas na impressão de etiquetas, etc.), mas em outros podem significar burlar a autenticação, alterar permissões ou manipular operações críticas..

Para que a vulnerabilidade HPP seja verdadeiramente explorável, o mecanismo de leitura de parâmetros do servidor ou framework deve ser retornar um valor diferente do esperado quando encontra parâmetros duplicados. A partir daí, o atacante pode manipular essa precedência para direcionar o fluxo do aplicativo a seu favor.

Como os servidores lidam com parâmetros duplicados

O principal elemento técnico que torna possível a produção de alta pressão reside no comportamento desigual dos diferentes fluidos. servidores web e linguagens de backend Ao processar parâmetros repetidos, nem todos agem da mesma forma, e essa variedade é justamente o que permite aos atacantes encontrar vulnerabilidades.

Em alguns ambientes, se enviarmos uma URL do tipo variável1=val1&variável1=val2o servidor só manterá o primeiro valor (val1). Em outros, levará o último valor recebido (val2). E em certos casos, como acontece com certas configurações de IIS, os dois valores são concatenar internamente em uma lista, por exemplo, separados por vírgulas, que o aplicativo terá então que interpretar.

Um exemplo frequentemente citado é que apache Em seu comportamento padrão, geralmente mantém o primeiro valor de um parâmetro e descarta os seguintes, enquanto outras tecnologias geram um Lista CSV (Valores Separados por Vírgula) com todos os valores desse parâmetro corrompido. Se a aplicação de backend estiver adaptada apenas a um desses casos, cenários não controlados podem causar efeitos inesperados.

Este tratamento de parâmetros duplicados afeta não só a lógica visível ao usuário, mas também controles de segurança internos, validadores de entrada, rotinas de autenticação e autorizaçãoO mesmo parâmetro pode ser verificado em um ponto da aplicação usando um valor e usado em outro ponto com um valor diferente, tudo dentro da mesma requisição.

Além disso, as centrais de alta pressão podem ser usadas para tirar proveito de transformações internas de caracteres o que o próprio servidor faz. Foi documentado, por exemplo, como alguns servidores alteram certos caracteres específicos (como o caractere "]" sendo substituído por "_") durante o processamento, o que pode ser usado para burlando regras de filtragem ou firmwares WAF com base em expressões regulares..

Consequências e cenários de exploração de usinas hidrelétricas

As técnicas de poluição de parâmetros HTTP permitem a geração de uma ampla gama de situações de risco, tanto no lado do servidor quanto no lado do cliente. A gravidade dessas situações depende do tipo de ataque. função do parâmetro afetado e o ponto no fluxo de aplicação em que é alterado.

Entre as consequências mais notáveis ​​observadas em aplicações vulneráveis ​​estão: sobrescrevendo parâmetros protegidosUm atacante pode adicionar mais de um valor para um parâmetro crítico e forçar o aplicativo a usar precisamente o valor malicioso, graças ao funcionamento da precedência nesse ambiente específico.

Também é comum que o HPP permita o modificação do comportamento esperado da aplicaçãoPor exemplo, alterando filtros em mecanismos de busca internos, modificando identificadores de recursos, manipulando operações de votação ou variando parâmetros que controlam a lógica de negócios (como sinalizadores de administrador, modos de depuração ou estados de transação).

Outra consequência importante é a evasão de validações de entradaSe o código de validação de segurança examinar a primeira ocorrência de um parâmetro, mas a operação real for realizada em uma ocorrência posterior, um invasor poderá burlar controles de segurança aparentemente bem implementados. Isso já foi observado em casos de bypass de autenticação e controle de acesso.

Em contextos mais complexos, o HPP pode desencadear erros internos da aplicação, exposição de informações sensíveis, acesso a variáveis ​​fora do escopo pretendido e até mesmo o uso de parâmetros concatenados que, uma vez remontados, formam cargas úteis que um WAF não detectou ao analisar cada parâmetro separadamente.

Em termos de impacto, foram observados ataques de ambos os lados. lado do servidor (contornando o WAF, alterando a reescrita de URLs, forçando rotas internas diferentes) a partir de lado do cliente (Injeção de parâmetros em links e formulários para enganar as vítimas por meio de URLs especialmente manipuladas).

Exemplo clássico de HPP em uma aplicação de votação

Para melhor compreender como funciona um ataque de poluição de parâmetros HTTP, vejamos o exemplo de um Aplicativo web de votação escrito em JSPonde os usuários podem votar em seu candidato favorito em diferentes eleições.

O aplicativo recebe através de um parâmetro chamado id_da_eleição O identificador da eleição atual. Com esse valor, o servidor gera uma página listando os candidatos disponíveis, cada um com um link para votar. O método Solicitação.getParameter("par") Em JSP, quando existem múltiplos valores para o mesmo parâmetro, ele sempre retorna o mesmo valor. primeiro valor.

Vamos imaginar uma URL como esta: http://servidor/eleccion.jsp?eleccion_id=4568A página resultante exibe um link para votar em cada candidato, por exemplo:

Link 1Eu voto no Sr. White.
Link 2Eu voto na Sra. Green.

Suponhamos que um usuário malicioso, que apoia um determinado candidato, perceba que o aplicativo não valida com sucesso o parâmetro choice_idAproveitando-se de uma vulnerabilidade do HPP, ele decide injetar o parâmetro. candidato dentro desse choice_id, codificando os delimitadores da string de consulta.

A URL que ele gera pode ser algo como: http://servidor/eleccion.jsp?eleccion_id=4568%26candidato%3DgreenNote que o atacante codificou o símbolo & como %26 e o ​​sinal = como %3D, de forma que, após a decodificação, eles se tornam um novo parâmetro candidato incorporado ao valor election_id.

Quando a vítima clica no URL manipulado, aparentemente acessa a eleição correta. No entanto, como o aplicativo usa o valor `election_id` para construir os links de votação, decodificar o valor injetado... Isso acaba incluindo um candidato extra na string de consulta resultante..

O resultado é que os links gerados internamente ficam mais ou menos assim:

Link 1Eu voto no Sr. White.
Link 2Eu voto na Sra. Green.

Não importa em qual dos dois links a vítima clique: o script O arquivo voting.jsp sempre recebe duas instâncias do parâmetro candidate.onde o primeiro valor é verde. Como o desenvolvedor usa a funcionalidade padrão do Java para obter um único valor, ele obtém apenas o primeiro valor do parâmetro candidato e descarta o segundo, que capturaria o voto real do usuário.

Graças a esse comportamento, a vulnerabilidade HPP permite que o atacante obrigar todos os votos computados nessa página a serem direcionados ao seu candidato.independentemente das escolhas da vítima na interface. Este é um exemplo muito claro de como um gerenciamento de parâmetros supostamente "simples" pode ter um impacto direto no integridade de dados e lógica de negócios.

Burla de autenticação: o caso do Blogger

Um dos exemplos mais notórios de exploração de poluição de parâmetros HTTP ocorreu no sistema de blogs de BloggerUma vulnerabilidade no tratamento de parâmetros permitiu que invasores obtivessem acesso a tornar-se administradores de blogs de outras pessoassimplesmente manipulando os parâmetros de uma requisição POST.

A solicitação problemática era algo como isto (simplificando a sintaxe):

POST /add-authors.do HTTP/1.1
security_token=attackertoken&blogID=attackerblogidvalue&blogID=victimblogidvalue&authorsList=attackermail%40gmail.com&ok=Convidar

O problema residia no fato de que o mecanismo de autenticação e verificação de segurança Eu estava apenas olhando para o primeiro parâmetro blogID que chegou na solicitação, verificando se o usuário tinha permissões sobre aquele blog. No entanto, a operação real que o autor convidado adicionou foi realizada usando o segunda ocorrência de blogID, que correspondia ao blog da vítima.

Graças a essa contradição interna, a forma como o servidor lidou com a parâmetros duplicadosO atacante conseguiu passar pelas verificações de segurança do próprio blog, mas executou a ação no outro blog. O resultado foi um bypass completo de autenticação com um único pedido bem elaborado.

Este caso demonstra muito bem como o HPP não é apenas uma “curiosidade técnica”, mas sim uma técnica com impactos reais nos sistemas de grandes fornecedoresAlém disso, destaca a importância das verificações de segurança e da execução de operações usando exatamente os mesmos valores de parâmetros, sem depender de precedência não controlada.

HPP e Firewall de Aplicação Web (WAF)

Muitas organizações dependem de um WAF como uma camada adicional para proteger seus aplicativos web contra ataques conhecidos. Esses firewalls são normalmente baseados em regras e assinaturas (expressões regulares) que são aplicadas aos parâmetros, cabeçalhos e até mesmo ao corpo das requisições HTTP.

O problema é que, na presença de parâmetros duplicados, um atacante pode fragmentar uma carga maliciosa em vários valores do mesmo parâmetroEmbora o WAF analise cada parâmetro separadamente, é possível que nenhum dos valores isolados corresponda às assinaturas do ataque, permitindo que a solicitação passe pelos filtros sem ser bloqueada.

Assim que essa solicitação chega ao servidor web, ao mecanismo de aplicação ou ao próprio servidor. reorganiza os valores de acordo com sua lógica interna. (por exemplo, concatenando-os com vírgulas ou pegando o último), resultando em uma string que, como um todo, constitui o ataque. Dessa forma, a mesma técnica de poluição de parâmetros permite Contornar WAFs que não estejam equipados para analisar o conjunto concatenado de valores..

Além disso, alguns WAFs que não funcionam como proxy reverso E aqueles que não têm uma visão completa do fluxo entre cliente e servidor, mas atuam mais como filtros pontuais, podem ser especialmente vulneráveis ​​a esses desvios de HPP. Aqueles baseados em tecnologias como Apache com um mecanismo de pontuação de parâmetros e análise estatística Eles tendem a se comportar melhor diante desse tipo de técnica.

Resumindo, o HPP demonstra que mesmo com um WAF configurado corretamente, A segurança não é garantida. Se a lógica da aplicação e do servidor lidar incorretamente com parâmetros duplicados, a proteção deve ser abrangente e levar em consideração como as solicitações são processadas em todos os níveis.

Casos reais, ferramentas e prevalência de HPP

Pesquisas acadêmicas e o trabalho de especialistas em segurança demonstraram que a poluição de parâmetros HTTP está longe de ser rara. Projetos como PAPAS (Sistema de Análise de Poluição por Parâmetros), impulsionados por pesquisadores como Carmen Torrano, foram projetados precisamente para Detectar automaticamente vulnerabilidades HPP em aplicações web de grande escala.

Em experimentos conduzidos em mais de 5000 sites extremamente populares (De acordo com rankings como o da Alexa), observou-se que quase 30% dos locais analisados Elas continham pelo menos uma página vulnerável a HPP. Ou seja, era possível injetar um parâmetro codificado em outra página existente e verificar se ele aparecia decodificado em algum URL ou formulário resultante.

Ainda mais impressionante é que perto do 47% das vulnerabilidades encontradas (o que equivale a cerca de 14% do total de locais) eram realmente explorávelpermitindo ataques que iam além de simples falhas de apresentação. Entre os sites afetados estavam Grandes nomes como Microsoft ou GoogleIsso deixa claro que nem mesmo as gigantes da tecnologia estão isentas desses problemas.

Ferramentas como PAPAS Eles serviram para analisar e quantificar o problema, mas também destacaram a dificuldade de detectar HPP automaticamenteMuitos scanners de vulnerabilidades web tradicionais não consideram adequadamente cenários com parâmetros duplicados, ou geram um volume muito alto de falsos positivos.

Além de soluções específicas como BATATAS, existem extensões como Localizador de HPP para Google ChromeEssas ferramentas são projetadas para detectar possíveis vetores de ataque HPP em URLs e formulários HTML. Embora possam ajudar a identificar pontos suspeitos (por exemplo, formulários que reutilizam parâmetros sem a devida validação), elas não constituem uma solução definitiva. Não é uma solução completa nem substitui uma auditoria de segurança aprofundada..

Outra ferramenta amplamente utilizada no ecossistema de testes de segurança é ZAP OWASPque inclui extensões e scripts para testar diferentes vetores, incluindo aqueles relacionados a parâmetros na string de consulta. No entanto, no caso específico do HPP, ainda é necessário combinar ferramentas automatizadas com Análise manual e compreensão do fluxo de aplicação.

HPP em mecanismos de busca internos e exemplos como Apple.com

Os HPPs não foram observados apenas em sistemas de gerenciamento de blogs ou painéis de administração, eles também aparecem em funções aparentemente inofensivas, como mecanismos de busca por tags em fóruns e comunidades online. Um exemplo marcante foi encontrado em Fóruns da Apple, onde a gestão de rótulos e parâmetros poluídos apresentou comportamentos curiosos.

Nesses fóruns, selecionar uma tag na interface adicionava um parâmetro. Tag A string de consulta na URL recebeu o valor da tag escolhida. O aplicativo de backend recuperou esse valor, pesquisou tópicos com essa tag e exibiu os resultados para o usuário. Se várias tags foram selecionadas, todas foram adicionadas. no mesmo parâmetro de tags, separados pelo operador de adição (+)Assim, o sistema estava pronto para processar essa lista.

Quando o parâmetro de tags foi poluído com vários valores duplicados, observou-se que a tecnologia de backend gerou um lista separada por vírgulas (CSV) com todos os valores de parâmetros corrompidos. O aplicativo conseguiu processar parcialmente essa lista (descobrir as diferentes tags), mas Nem todas as etiquetas foram impressas corretamente. no campo de texto do mecanismo de busca.

Nesse contexto específico, não parecia haver nenhuma falha de segurança explorável, mas era evidente que Existiram cenários não considerados pelos desenvolvedores.Em outras aplicações, menos inocentes, comportamentos semelhantes poderiam levar a discrepâncias entre o que é validado, o que é usado e o que é mostrado ao usuário., com consequências mais graves.

A análise das tecnologias subjacentes em fóruns como o da Apple (por exemplo, Apache com J2EE no backend) mostra que muitas stacks modernas se comportam de maneira semelhante a servidores como o IIS ou combinações como Apache com Python ao lidar com parâmetros poluídos, gerando listas separadas por vírgulas e delegando o tratamento final desses valores à lógica da aplicação.

Esses tipos de exemplos servem como um lembrete de que Não basta que "pareça funcionar" em casos normais.É preciso testar sistematicamente como o aplicativo reage ao receber parâmetros duplicados, valores com códigos estranhos, combinações incomuns, etc., pois é aí que o HPP encontra seu nicho.

Detecção e mitigação da poluição de parâmetros HTTP

A detecção e mitigação de HPP requerem uma abordagem híbrida que combine Boas práticas de desenvolvimento seguro, configuração adequada do servidor e uso de ferramentas específicas.Não basta confiar no WAF para resolver tudo, porque, como vimos, muitas vezes é justamente essa camada que pode ser enganada.

Do ponto de vista do desenvolvimento, é essencial que os programadores Tenha em mente que um parâmetro pode ter múltiplos valores. E eles devem decidir explicitamente como lidar com esse caso. Não devem confiar nos comportamentos padrão da linguagem ou do framework sem um entendimento completo de como funciona a precedência de valores.

Recomenda-se também que, em pontos críticos como autenticação, autorização, operações sensíveis ou mudanças de estado importantesÉ rigorosamente verificado se os parâmetros aparecem apenas uma vez, rejeitando solicitações com parâmetros duplicados ou, pelo menos, registrando-as para análise.

Em relação à infraestrutura, é aconselhável revisar o Configurações do servidor web e do framework Para entender exatamente o que acontece quando um parâmetro repetido é recebido: se o primeiro, o último ou todos eles concatenados são mantidos. A partir daí, a lógica do aplicativo pode ser ajustada para evitar discrepâncias entre a validação e o uso real do valor.

Em termos de ferramentas, além dos scanners de vulnerabilidades usuais, é útil incorporar soluções específicas, como... PAPAS ou tipo de extensões Localizador HPP no fluxo de teste. Se o OWASP ZAP ou outras ferramentas de pentest forem utilizadas, vale a pena criar scripts específicos que gerem solicitações com parâmetros duplicados e valores codificados de maneiras diferentes Observar a reação da aplicação.

Por fim, é importante reconhecer que o processamento por alta pressão (HPP) é um problema. muito mais disseminado do que se costuma pensarIsso é especialmente verdadeiro em grandes aplicações com muitos anos de evolução. Combinar treinamento, revisão de código, testes automatizados e testes manuais bem elaborados é a melhor maneira de manter esses erros sob controle.

A contaminação de parâmetros HTTP conquistou merecidamente seu lugar entre as técnicas de ataque web que qualquer equipe de desenvolvimento e segurança deve ter em seu radar: É discreto, difícil de detectar com um simples olhar para os registros e pode ter consequências muito sérias. Se isso afetar parâmetros-chave da lógica de negócios ou dos controles de segurança, entender como os parâmetros duplicados são tratados em sua infraestrutura e testar ativamente esses cenários é uma daquelas tarefas que podem parecer um pouco tediosas no início, mas faz toda a diferença entre um aplicativo meramente funcional e um que seja verdadeiramente robusto contra ataques avançados.