Um pouco sobre teste de parâmetros em aplicações web

 Introdução

Neste artigo vamos abordar testes em entradas de dados em uma aplicação web. Durante o artigo teremos uma explanação de como algumas ferramentas funcionam para testar sua aplicação web.

Quando falamos de testes em entradas de aplicações Web, muitos pensam em TDD (Test Driven Development), logo alguns iram citar até o Selenium. Embora o Selenium tenha poder para nos ajudar, o uso do browser seria na maioria dos casos inútil. Lembre-se que nosso foco é testar entradas para verificar existência de padrões nas respostas, julgando a segurança da aplicação e não a funcionalidade de uma aplicação.

Ferramentas

Embora seja interessante reinventar a roda por motivos de aprendizado ou otimização, temos em nosso alcance um grande número de ferramentas que podem ajudar nos testes.

Uma das ferramentas disponíveis é o Burp Suite, com ele poderíamos usar o intruder, para alterar os valores dos parâmetros de uma request HTTP e analisar a resposta buscando por padrões que são característicos de uma aplicação vulnerável.

Além do Burp, temos scanner de vulnerabilidades como o Skipfish e Arachni que fazem a tarefa de mapeamento do alvo bem como um "sitemap", ou seja, é feita a abstração de todas as URLs do alvo de forma recursiva,  e analisado os dados para identificar uso de entradas e, de forma automática, é feito um teste nas entradas encontradas.

Reinventando a roda, mas por um bom motivo

Pensando no aprendizado apresento a vocês o 0d1n, uma ferramenta para testar entradas em aplicações web. Essa aplicação possui código fonte simples por ter poucas funções, e usa libCurl pela praticidade para executar uma request e obter  a resposta.

Supondo que você use algum derivado de unix siga os seguintes passos:

 $ wget http://0d1n.googlecode.com/files/0d1n_stable_v9.zip
 $ unzip -e 0d1n_stable_v9.zip; cd 0d1nstable
 $ make

lembrando que você precisa da "libCurl", caso esteja em um linux derivado de debian, por exemplo, basta o seguinte comando para instalar:

 $ apt-get install libcurl-dev

Estamos preparados para usar o programa conforme a Figura 1.

 $ ./0d1n

Figura 1

Como usar a ferramenta

O caractere “!” é um indicador de onde você deseja injetar os valores que estão na sua lista de payloads.

Exemplo:

site.com/site.jsp?login=admin&pass=!

Neste caso o programa irá trocar todos os “!” por strings que estão presentes em uma determinada lista(chamamos de lista de payloads), enviaria um "request" e procuraria determinadas strings que estão em "response2find". Se contiver qualquer string do "response2find" será salvo em um log o "response".

Outro exemplo:

http://site.com/index.jsp?var=1&feijoada=3
http://site.com/index.jsp?var=!&feijoada=!

Logo se a primeira linha da lista de payloads for ” or 1=1” nosso programa irá executar:

site.com/index.jsp?var= or 1=1&conviso=3

Para testar parâmetros POST usamos o argumento -P e o argumento -h seria o local onde receberia o POST.

Exemplo:

-h ‘http://site.com/index.jsp ‘ –P ‘var=!&var2=!&var3=teste’

Prova de Conceito

Para testar a ferramenta vamos usar o DVWA. Com o DVWA rodando vamos alterar o Security Level para Low no menu Security Level.

Antes, precisamos do Cookie da sessão do DVWA, pois para explorar o XSS preciamos estar autenticado na aplicação. Portanto logue no sistema e salve o “cookie jar”. Para isso podemos usar o plugin Export Cookie do firefox.

Tendo o Cookie da sessão em mãos definimos um alvo. Agora vamos explorar um reflected XSS na url  http://localhost/dvwa/vulnerabilities/xss_r  executando o seguinte comando:

$ ./0d1n -h ‘http://localhost/dvwa/vulnerabilities/xss_r/?name=!‘ -p payloads/list.txt -f response2find/find.txt -c cookies_dvwa.txt -o dvwa

Para analisar o resultado abrimos o arquivo "tables/hammer.html".

Nas linhas da tabela da Figura 2 podemos ver o padrão que buscamos no conteúdo da página e clicando nela podemos identificar uma requisição onde o payload XSS foi executado e demonstra que a aplicação é vulnerável a XSS conforme a Figura 3.

Figura 2 

Figura 3

Um pouco sobre o código fonte

Com uso simples de "sockets" podemos nos comunicar usando protocolo HTTP, automatizando o envio de entradas e analise das respostas.

Vamos analisar o código fonte do programa em "spider.c" (linha 46) onde é feito a  construção da request com libCurl usando macros para setopt.

// injeta payload
    make=payload_injector( (POST?arg[4]:arg[0]),line,old);
    curl = curl_easy_init();
    curl_easy_setopt(curl,  CURLOPT_URL, POST?arg[0]:make);
// caso seja post
     if(POST)
      curl_easy_setopt(curl, CURLOPT_POSTFIELDS, make);
// escreve o "response" na memória
    curl_easy_setopt(curl,  CURLOPT_WRITEFUNCTION, WriteMemoryCallback);
    curl_easy_setopt(curl,  CURLOPT_WRITEDATA, (void *)&chunk);
// caso seja definido useragent
    if(arg[6]!=NULL)
    {
     curl_easy_setopt(curl,  CURLOPT_USERAGENT, arg[6]);
    } else {
     curl_easy_setopt(curl,  CURLOPT_USERAGENT, "Mozilla/5.0 (0d1n v0.1) ");
    }
 // para comprimir os dados e ganhar desempenho
    curl_easy_setopt(curl,  CURLOPT_ENCODING,"gzip,deflate");
// caso queira usar cookiejar
    if(arg[3]!=NULL)
    {
     curl_easy_setopt(curl,CURLOPT_COOKIEFILE,arg[3]);
     curl_easy_setopt(curl,CURLOPT_COOKIEJAR,arg[3]);
    } else {
     curl_easy_setopt(curl,CURLOPT_COOKIEJAR,"odin_cookiejar.txt");
    }
    curl_easy_setopt(curl,CURLOPT_FOLLOWLOCATION,1);
//caso queira carregar um certificado
    if(arg[7]!=NULL)
    {
     curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, 1);
     curl_easy_setopt(curl, CURLOPT_SSL_VERIFYHOST, 2);
     curl_easy_setopt(curl, CURLOPT_CAINFO, arg[7]);
    } else {
     curl_easy_setopt(curl,CURLOPT_SSL_VERIFYPEER,0);

Na linha 104, temos uma busca pela string de "response2find/*" dentro do response, repare que não usamos a função strstr(), e sim bitap, que procura uma substring aproximada a de um determinado padrão.

if(chunk.memory && bitap_search(chunk.memory,line2))

Conclusão

Concluímos então que com a simplicidade dessa ferramenta, podemos facilmente entender o funcionamento de um teste de entradas de uma aplicação de web, ver as etapas do teste de forma transparente. 

Autor do Post

Antonio Costa "Cooler_" é desenvolvedor em ASM,C,Common Lisp,Perl e outras linguagens, foi um dos escritores da e-zine cogumelo binário,é um dos fundadores do grupo de estudo e pesquisa BugSec, já palestrou em alguns eventos como OWASP,YSTS e Bsides, Nas suas horas livres gosta de tomar todynho e colecionar gibis, brinca com microcontroladores AVR e eletrônica, apesar de ser perna de pau nunca recusa uma boa pelada dia de domingo.