Como forma de tornar o tráfego simulado o mais semelhante possível a tráfego real, foram criados diversos perfis de utilizador tipo, de forma a caracterizar diferentes comportamentos de navegação. Através da simulação de navegações com as características de cada um dos vários perfis de utilizadores é possível gerar tráfego de acesso a um determinado website que, estando a ser monitorizado pelo sistema de user tracking proposto neste trabalho, possibilitará a recolha da informação necessária para identificar e agrupar as visitas dos diferentes utilizadores. Podem ser assim obtidos registos em que constam diversos utilizadores, com características diferentes, que o sistema tentará identificar e correlacionar. Tendo a informação do tráfego gerado, sabendo, a partir dos registos das simulações, quantos e quais os perfis que foram utilizados e quais as visitas de cada um deles, é possível determinar a eficácia do sistema em vários cenários diferentes e testar e comparar diversas abordagens procurando aperfeiçoá-lo.
22B6.3.1 – Definição dos perfis de utilizadores a simular
Considerando o contexto proposto para este trabalho, procurou-se definir um conjunto de diferentes perfis de utilizadores em que cada um representasse comportamentos de
53
navegação de utilizadores reais com diversas preocupações e objectivos, desde utilizadores padrão, que não apagam constantemente os cookies e mudam de endereço IP de longe a longe, a utilizadores com preocupações sobre segurança e privacidade, que apagam frequentemente ou rejeitam cookies e podem até utilizar vários browsers diferentes, até ao extremo dos utilizadores que executam Click Fraud, ver Secção 2.3, procurando de todas as formas não serem identificados. Foram, desta forma, considerados três grandes grupos de utilizadores: utilizadores Padrão, utilizadores com preocupações de Segurança (ou simplesmente Segurança) e utilizadores Maliciosos. Para diferenciar o comportamento destes grupos foi necessário seleccionar um conjunto de elementos identificadores que os utilizadores podem tentar alterar ou falsificar entre as suas visitas Web. De facto, foram colocados nesse conjunto todos os elementos que o sistema de user tracking proposto recolhe e nos quais se baseia para identificar e associar as visitas dos utilizadores. Os diversos perfis de utilizadores, utilizados nas simulações de navegação para avaliação do sistema, estão caracterizados na 132HTabela 6.1.
Tabela 6.1 - Perfis de utilizadores para simulação Perfil de
Utilizador
Informação Alterada/Falsificada entre cada visita
IP IP Interno Cookie Flash Cookie User Agent Assinatura Browser
Padrão Segurança (1) X Segurança (2) X X Segurança (3) X X X Malicioso (1) X X X X X Malicioso (2) X X X X X Malicioso (3) X X X X X X X
Apesar de todos os elementos identificadores presentes na 133HTabela 6.1 já terem sido
apresentados anteriormente, talvez seja importante prestar alguns esclarecimentos. Estão presentes dois campos referentes a endereços IP; o primeiro diz respeito ao endereço público obtido a partir dos pedidos HTTP que são realizados quando cada utilizador chama os ficheiros que contêm o código do JIC, o segundo campo é informação capturada através da ronda Java do JIC e fornece o endereço IP da placa de rede da máquina do utilizador, que geralmente não é visto fora da sua rede local. O elemento User Agent refere-se ao campo homónimo dos cabeçalhos HTTP que geralmente contém uma string que depende do browser que gera os pedidos, no entanto, este campo é facilmente falsificável e desta forma é possível avaliar a sua influência nos resultados do sistema, nomeadamente na associação de visitas através da assinatura onde este parâmetro é utilizado. O elemento identificador Assinatura diz respeito
54 Metodologia de Teste
a todos os restantes parâmetros recolhidos através do JIC, em todas as suas rondas, que são utilizados para a associação de visitas pelo método com o mesmo nome.
23B6.3.2 – Arquitectura do sistema de simulações
Para que se conseguissem simular cada um dos perfis de utilizador propostos era necessário encontrar uma forma de alterar, falsificando, cada um dos elementos definidos de forma automática. O primeiro passo consistiu em encontrar uma ferramenta que suportasse a utilização de vários browsers, preferencialmente os mais utilizados actualmente. A solução encontrada foi o Selenium RC [30], um sistema desenhado para a realização de testes de usabilidade em websites, que permite, de forma automatizada, executar as interacções típicas entre um utilizador e um browser, como por exemplo cliques sobre objectos das páginas Web ou preenchimento de formulários. Este sistema suporta a maior parte dos browsers mais populares e é baseado numa arquitectura do tipo cliente-servidor, representada na 134HFigura 6.1, adaptada de [30]. Nesta arquitectura, o processo cliente efectua
pedidos numa linguagem própria, o selenês, que o servidor interpreta e comunica ao Selenium Core no browser. Recorrendo à numeração da 135HFigura 6.1, é possível perceber a
ordem das operações:
1. Estabelecimento da ligação entre o cliente e o servidor Selenium.
2. O Selenium RC Server lança um novo browser (seleccionado pelo cliente).
3. O Selenium Core, a correr no browser, recebe uma instrução do cliente através do Selenium RC Server.
4. O Selenium Core executa a instrução no browser (a primeira instrução é tipicamente abrir uma determinada página que será testada).
5. O browser comunica com o servidor Web que contém a página pedida e mostra-a no ecrã (navegação idêntica à efectuada por um utilizador humano).
O Selenium RC é open source o que permite a adaptação do código para os propósitos deste trabalho e, uma vez que de entre as várias linguagens de programação diferentes em que está implementado se encontra uma versão em Java, constitui um sistema multi- plataforma, como era desejado. No entanto, o Selenium RC não foi desenhado para esconder a identidade dos seus utilizadores e, com a excepção do controlo de cookies HTTP, para os quais existem funções de atribuição, leitura e limpeza já definidas, através do selenês não existe forma de alterar os elementos identificadores que foram considerados e, por isso, outras formas de os controlar tiveram que ser encontradas. Para que se conseguisse apagar os Flash cookies foi criada uma função em Java que acede directamente aos ficheiros em disco e os remove quando necessário. A alteração dos endereços IP foi baseada na leitura das configurações a partir de um ficheiro e, opcionalmente, através da utilização de um servidor DHCP. Este ficheiro de configuração inclui todos os parâmetros necessários para a execução
55
de todos os tipos de simulação, desde a definição dos elementos que deviam ser alterados entre visitas, até ao número de visitas a realizar por simulação, endereço IP a utilizar, URL da página a visitar, browser a utilizar, etc.
Figura 6.1 - Arquitectura do Selenium RC
Através da utilização do Selenium RC, e apesar de todas as modificações acrescentadas, a alteração do campo User Agent e dos restantes parâmetros da assinatura não era exequível. O Selenium apenas permite o controlo a montante do browser, isto é, uma vez que implementa apenas as acções típicas de um utilizador sobre as páginas apresentadas pelos browsers, todas as comunicações entre os browsers e os servidores Web não estão acessíveis. Para que se conseguisse alterar estes elementos de identificação era necessário interceptar e alterar os pedidos HTTP efectuados pelos diversos browsers controlados pelo Selenium. O WebScarab [31] é uma framework desenhada para permitir a análise de aplicações que comuniquem através dos protocolos HTTP e HTTPS. Apresenta várias funcionalidades mas, de forma simples, pode ser encarado como um proxy HTTP/HTTPS open source. Implementado em Java, aceita scripts escritos numa linguagem semelhante a Java, o BeanShell15. Com estes
scripts é possível a alteração dos pedidos que passam através do WebScarab. Foram desenvolvidos scripts nesta linguagem que permitem a alteração do campo User Agent, de
15 BeanShell [32], é uma linguagem de scripting, interpretada numa máquina virtual Java, que estende a linguagem Java ao permitir a utilização de características próprias de linguagens de scripting, como a possibilidade de não se atribuir tipos às variáveis, e a utilização de comandos e métodos tal como em Perl e JavaScript.
56 Metodologia de Teste
forma a que cada visita ao website auditado gere tráfego com um User Agent único, e possibilitam ainda a falsificação dos parâmetros recolhidos para a geração da assinatura digital. Este último script foi desenvolvido com o objectivo de alterar, de forma aleatória, os parâmetros individuais capturados em cada uma das rondas do JIC. Contudo, implicou um conhecimento pormenorizado da arquitectura do JIC, uma vez que foi necessário saber em que pedidos a informação era transmitida, como estava dividida, em que parâmetros é que era passada, o método de encriptação dos dados e a chave correspondente, etc.
Figura 6.2 - Arquitectura de Simulação com WebScarab
Juntando todos os componentes necessários, obteve-se a arquitectura de simulação de tráfego necessária para a avaliação do sistema de user tracking desenvolvido. Observando a
136HFigura 6.2 pode constatar-se o funcionamento geral do sistema:
1. O Simulation Manager, cliente do Selenium expandido, carrega as configurações da simulação a partir de um ficheiro.
2. O próprio Simulation Manager lança o processo do Selenium RC Server e estabelece a comunicação.
3. O Selenium RC Server executa as instruções do Manager instanciando um novo browser e iniciando a navegação da página auditada.
4. Os pedidos HTTP do browser são automaticamente encaminhados para o WebScarab que, conforme os scripts activos, os altera.
57
6. As respostas do Servidor Web passam inalteradas pelo WebScarab para o browser. 7. O Simulation Manager regista as propriedades da simulação e os identificadores
únicos para cada visita à página Web auditada.
De notar que o WebScarab não necessita de estar activo nas simulações que não incluam a alteração do campo User Agent ou falsificação dos parâmetros para a assinatura digital, sendo que, através do ficheiro de configuração, é possível definir se os pedidos dos browsers utilizados durante a simulação deverão ser ou não encaminhados através do proxy.
Esta arquitectura permite ainda cenários mais complexos e variados, que não foram utilizados neste trabalho, com por exemplo várias simulações diferentes a decorrer simultaneamente em várias máquinas, simulando vários utilizadores acedendo ao website ao mesmo tempo, como se encontra representado na 1 37HFigura 6.3.
Figura 6.3 - Exemplo de cenário de operação do sistema de simulação de utilizadores