Ataques Web: HTTP Parameter Pollution

Nesse post irei tratar sobre uma técnica relativamente nova e pouco comentada/discutida, que vem sendo utilizada por atacantes com o objetivo de "bypassar" filtros HTTP baseados em black list.

Em 2009 durante uma palestra no OWASP AppSec Europa, os pesquisadores Stefano di Paola e Luca Carettoni discorreram em sua apresentação sobre uma nova técnica chamada de HTTP Parameter Polution. Essa técnica consiste basicamente em explorar a forma de como os servidores de aplicação tratam variáveis multi valoradas, a fim de subverter o fluxo lógico de uma aplicação web, filtros, firewalls de aplicação, etc.

Para entendermos melhor como funciona essa técnica, observe a tabela abaixo que descreve como se comportam vários servidores de aplicação quando recebem variáveis multi valoradas:

Como podemos observar na imagem, existem 4 comportamentos padrões entre os servidores web ao receberem parâmetros multi valorados, são eles:

  • Utilizar somente o primeiro valor repassado;
  • Utilizar somente o último valor repassado;
  • Concatenar todos os valores utilizando um separador;
  • Transformar os valores em um array;

Baseando-se nisso, um atacante pode construir uma requisição que será capaz de "bypassar" um filtro de Cross-Site Scripting ou SQL Injection de um firewall de aplicações. Para ilustrar melhor essa afirmação, considere o seguinte cenário:

  • Uma aplicação .NET que esteja rodando em um servidor IIS 6;
  • Um firewall de aplicações que utilize regras de black list e que valida os parâmetros separadamente;
  • Que este firewall de aplicações esteja utilizando a seguinte regex para filtrar ataques de Sql Injection:

 .*(union)?.*select.*(from)?.*(where)?.* 

HTTP Parameter Pollution na prática

Ao realizarmos a seguinte requisição:

 /noticia.aspx?id=-999 union select 1,2,3 from tabela where id_noticia=1 

Ela será facilmente detectada pelo filtro do firewall de aplicações. Porém, se fizermos a seguinte requisição:

 /noticia.aspx?id=-999&id=union&id=select&id=1,2,3&id=from&id=tabela&id=where&id=id_noticia=1 

Ela não será detectada, pois como o firewall de aplicações analisa os parâmetros separadamente, ele primeiro irá validar a string -999, depois a string union, depois a string select, depois a string 1,2,3... e assim por diante. Porém, quando a requisição chegar no servidor de aplicações, como já sabemos, o IIS irá concatenar todos os valores de id com vírgulas, gerando o seguinte payload:

 -999,union,select,1,2,3,from,tabela,where,id_not=1 

Logo, o filtro será "bypassado". Porém, o payload gerado não é uma query sql válida. Entretanto, se enviarmos a seguinte requisição:

 /noticia.aspx?id=-999/*&id=*/union/*&id=*/select/*&id=*/1,2,3/*
&id=*/from/*&id=*/tabela/*&id=*/where/*&id=*/id_not=1 

O payload gerado será:

 -999/*,*/union/*,*/select/*,*/1,2,3/*,*/from/*,*/tabela/*,*/where/*,*/id_not=1 

Que de fato é uma query sql válida, pois quando essa query é executada pelo banco de dados, o comentário /*,*/ é desconsiderado e substituído por um espaço, então, caso a aplicação em questão seja vulnerável a SQL Injection, a mesma será atacada apesar da existência de um firewall de aplicações filtrando as requisições.

Comentários
Aceita-se formatação à la TWiki. HTML e scripts são filtrados. Máximo 15KiB.

 
Enviando... por favor aguarde...
Comentário enviado com suceso -- obrigado.
Ele aparecerá quando os moderadores o aprovarem.
Houve uma falha no envio do formulário!
Deixei uma nota para os admins verificarem o problema.
Perdoe-nos o transtorno. Por favor tente novamente mais tarde.