PONTIFÍCIA UNIVERSIDADE CATÓLICA DO PARANÁ ESCOLA POLITÉCNICA

CURSO DE ENGENHARIA DE COMPUTAÇÃO

PEDRO FERNANDES DALLEGRAVE

RELATÓRIO FINAL

INTERPROXY – APLICATIVO MOBILE PARA ANÁLISE HTTP

Relatório final apresentado na

disciplina Projeto Final II do Curso de Graduação em Engenharia de Computação da Pontifícia Universidade Católica do Paraná como forma de avaliação referente a 2a Parcial.

Orientadora: Profa. Deborah Carvalho

CURITIBA 2014

RESUMO Este projeto visa facilitar a realização de testes de segurança em aplicativos

para dispositivos móveis ao desenvolver uma ferramenta de intercepting proxy HTTP. Atualmente não existe este tipo de ferramenta para os dispositivos móveis, sendo necessária a utilização de uma infraestrutura extra para realização dos testes. Ou seja, é necessário que os testes sejam realizados em um emulador ou utilizando um computador como proxy. Desta forma, ao criar a ferramenta os testes poderão ser realizados utilizando apenas o dispositivo móvel. Este projeto se propõe a disponibilizar esta ferramenta para a plataforma Android, ficando como proposta de trabalhos futuros a implementação em outras plataformas, por exemplo iOS e Windows Phone.

SUMÁRIO

1   INTRODUÇÃO  ................................................................................................................  3  

2   DETALHAMENTO  DO  PROJETO  ......................................................................................  6  2.1   HIGH-­‐LEVEL  DESIGN  ..........................................................................................................  6  

2.1.1   Módulos  .................................................................................................................  6  2.1.1.1   Módulo  de  servidor  ....................................................................................................................  6  2.1.1.2   Módulo  de  banco  de  dados  ........................................................................................................  6  2.1.1.3   Interface  gráfica  ..........................................................................................................................  7  

2.2   LOW-­‐LEVEL  DESIGN  ...........................................................................................................  7  2.2.1   Diagrama  de  Sequência  .........................................................................................  7  2.2.2   Diagrama  de  Classe  ...............................................................................................  8  

2.3   REQUISITOS  ...................................................................................................................  10  2.3.1   Requisitos  Não-­‐Funcionais  ...................................................................................  10  2.3.2   Requisitos  Funcionais  ...........................................................................................  10  

3   TESTES  E  RESULTADOS  ................................................................................................  12  3.1   MÓDULO  DE  SERVIDOR  ....................................................................................................  12  3.2   MÓDULO  DE  BANCO  DE  DADOS  .........................................................................................  12  3.3   INTERFACE  GRÁFICA  ........................................................................................................  13  

4   CONCLUSÃO  ................................................................................................................  14  

5   REFERÊNCIAS  ..............................................................................................................  15  

3

1 INTRODUÇÃO

Está se tornando cada vez mais comum a utilização de dispositivos móveis

para ações cotidianas. Estes são utilizados para acesso à redes sociais, contas bancárias, dados de cartão de crédito, email, fotos, entre outros. Além disto existem as aplicações corporativas, que estendem as redes para além do seu perímetro interno e, portanto, podem potencialmente expor essas organizações para um novo tipo de ameaça.

O risco associado com essas aplicações, em geral, pode ser identificado e mitigado através da realização de testes de segurança. Comparadas com aplicações desktop ou web, as aplicações mobile exigem um cenário mais complexo para execução dos testes de segurança e por este motivo acabam não sendo efetuados. E isto, gera um risco maior para o acesso de informações na plataforma móvel.[7][8]

Testes de segurança em aplicações, neste caso em aplicações para dispositivos móveis utilizam uma metodologia de modo a facilitar a sua execução e garantir os resultados. Esta metodologia em geral envolve passos que vão desde o reconhecimento da aplicação, passam pela avaliação de componentes e comportamentos esperados e por fim a execução de casos de teste. Durante estes passos diversas ferramentas são utilizadas de modo a facilitar a sua execução e automatizar determinadas tarefas.

A execução dos casos de teste envolve verificar se condições levantadas durante as fases anteriores ocorrem ou não. Estas situações, quando ocorrem, são chamadas de vulnerabilidades e representam uma ameaça para a aplicação. A Open Web Application Security Project Foundation (OWASP) lista a cada 2 anos as 10 vulnerabilidades mais comuns encontradas em aplicações. E, na sua maioria, temos vulnerabilidades que podem ser exploradas através da modificação dos dados que a aplicação envia para o servidor. Entre elas podemos citar as vulnerabilidades de injeção, gerenciamento de sessão, XSS entre outras. [2]

Uma forma que os desenvolvedores utilizam para proteger os seus sistemas destas vulnerabilidades é limitar o que o usuário pode digitar na aplicação cliente e assim impedir que o servidor receba dados inválidos. Entretanto este tipo de segurança não é válida pois pode ser facilmente contornada quando se utilizam ferramentas auxiliares, dentre as quais podemos citar o Intercepting Proxy. Esta ferramenta tem como principal função executar o papel de proxy entre a aplicação cliente e servidor e modificar os dados trafegados, de modo que as limitações impostas a aplicação cliente sejam ignoradas.[9][10]

Como exemplos deste tipo de aplicações para o ambiente desktop temos o Paros Proxy (Figura 1), Burp Proxy (Figura 2) entre outros. [3][4]

4

Figura 1 - Paros Proxy

Figura 2 - Burp Proxy

Entretanto quando se trata de dispositivos móveis, não existe uma ferramenta que realize essa tarefa. As soluções adotadas até então são configurar a ferramenta de proxy em um desktop e redirecionar todo o tráfego do dispositivo móvel para ele ou emular o dispositivo móvel no computador. Porém tais soluções não são práticas e inviabilizam a execução dos testes sem o suporte de um desktop.

Portanto a proposta desse projeto é desenvolver uma ferramenta de Intercepting Proxy para dispositivos móveis chamada InterProxy. Esta ferramenta teria como principal função auxiliar na execução de testes de segurança, também

5

conhecidos como pentest, ao ser capaz de modificar os dados trafegados entre as aplicações cliente executadas nos dispositivos móveis e os servidores com os quais essas aplicações se comunicam. De modo a possibilitar que não seja necessário nenhum equipamento adicional, apenas o dispositivo em questão. Na Figura 3 temos uma ilustração do fluxo modificado dos dados, onde as aplicações passam a se comunicar com a web através do InterProxy.

Figura 3 - Visão macro do funcionamento

Devido a limitações de hardware e de esforço disponível para o desenvolvimento deste projeto algumas restrições serão adotadas. A primeira diz respeito a plataforma para qual a ferramenta será desenvolvida, sendo adotada a plataforma Android. Segundo, apenas o tráfego HTTP será gerenciado pois para manipular dados de conexões HTTPS é necessário quebrar a conexão em dois tráfegos distintos, fazendo com que o Proxy estabeleça uma conexão com o cliente e outra com o servidor. Além disto seria necessário também a criação de conjuntos de certificados para estas conexões HTTPS. Por fim temos a restrição referente aos dados armazenados, pois a capacidade de armazenamento, a qual é um fator limitante, deste modo serão armazenados apenas os dados HTTP de pacotes cujo mime-type seja application, message e text. Tais questões poderão ser revistas em trabalhos futuros.

Este documento será composto de 5 seções descritas a seguir. A primeira é o Detalhamento do Projeto, a qual corresponde a uma descrição aprofundada da solução proposta. Onde serão apresentados os módulos que compõem o sistema, bem como os diagramas estruturais. Na seção 2 será apresentado o cronograma das atividades. A seção 3, Procedimentos de teste e validação do projeto, descreve os testes a serem realizados em cada módulo do sistema, os respectivos critérios de aceitação e a relação com os requisitos quando possível. A Análise de Risco, seção 4, descreverá os riscos possíveis ao projeto e seus impactos. Por fim a seção 5, conterá a Conclusão, onde são abordadas as definições do projeto bem como suas consequências e contribuições.

6

2 DETALHAMENTO DO PROJETO

2.1 HIGH-LEVEL DESIGN

2.1.1 Módulos

Figura 4 - Modelo de desenvolvimento

O diagrama apresentado na Figura 4, o modelo MVC, foi utilizado para

direcionar o desenvolvimento dos módulos que irão compor o aplicativo. O Controller será subdividido em 2 módulos, servidor e banco de dados, o View será representado pelo módulo de Interface gráfica e, por fim, o Model será a API org.apache.http.HttpMessage do Android. Cada um destes módulos e suas interações serão descritos a seguir.

2.1.1.1 Módulo de servidor

Este módulo será responsável por realizar toda a comunicação do aplicativo com os sistemas externos, Internet e aplicativos Android. Para isto o mesmo irá receber conexões HTTP através de uma porta TCP especificada nas configurações, receber as mensagens de Request, desempacotar as mesmas e enviar os dados para o módulo de banco de dados. No sentido inverso o módulo de servidor receberá dados do banco de dados, inserirá os mesmos em uma mensagem HTTP e enviará para servidor de destino. Além disto, sempre que o usuário habilitar a função de bloqueio, intercept o fluxo de mensagens será interrompido e o usuário poderá decidir o que fazer com as mesmas, encaminhar ao destino, descartar ou aceitar os dados modificados da interface e enviar ao destino.

2.1.1.2 Módulo de banco de dados

Todas as operações de banco de dados serão controladas através deste módulo, que fará o papel de DAO (data access object). As instruções para inserção, remoção e consulta de dados do banco serão enviadas pelo módulo de servidor e

7

interface. As consultas serão apenas para atualizar a interface gráfica com as informações mais atuais e modificar a ordenação da apresentação de acordo com as colunas da lista de apresentação. As inserções poderão ter seus dados originados a partir de dois módulos, servidor e interface gráfica. Os dados originados do módulo de servidor são recebidos externamente a aplicação, através das aplicações clientes ou servidores. Já os dados da interface gráfica são criados pelo usuário, seja modificando dados de uma mensagem pré-existente ou dados novos.

2.1.1.3 Interface gráfica

Por fim, o módulo de interface gráfica, este será responsável por determinar a interação com o usuário. Na interface o usuário poderá visualizar todas as mensagens armazenadas no banco de dados em forma de uma lista, que representa o histórico de todas as comunicações que passaram pela aplicação. Esta lista será separada em colunas para facilitar a visualização de dados importantes das mensagens e permitir a ordenação de acordo com os mesmos. Além disto, quando o usuário selecionar uma mensagem nesta lista a mesma será apresentada completa, de modo a permitir ao usuário visualizar todo o conteúdo da mensagem e a resposta correspondente a ela. Esta visão completa permitirá que o usuário edite e envie uma mensagem cuja conexão foi bloqueada, quando a opção de intercept é habilitada. Outra funcionalidade da lista de mensagens é permitir que uma ou mais linhas sejam excluídas, removendo as respectivas entradas do banco de dados.

2.2 LOW-LEVEL DESIGN

2.2.1 Diagrama de Sequência

O diagrama de sequência é responsável por representar o fluxo de processos, ou seja mensagens, entre os diferentes objetos que compõem a aplicação. Nele são apresentadas algumas sequências de dados através das chamadas de métodos e seus respectivos retornos para a execução de funções específicas do sistema.

Na Figura 5 temos o diagrama de sequência correspondente ao fluxo de uma mensagem recebida até a interface gráfica e o retorno de uma mensagem da interface para módulo de servidor. O fluxo tem seu início com a chamada do método receiveMessage, que recebe uma mensagem, em seguida a mesma é encaminhada para o openMessage e segmentada em dados. Depois de armazenada através do método save que invoca o insert, o qual por sua vez requisita uma conexão com o banco de dados usando o método openConnection. Para o fluxo inverso dados são gerados na interface gráfica pelo usuário com o método getUserData, o controlador coleta os mesmos da interface utilizando o getMessage e envia para o servidor, o qual irá montar estes em uma mensagem e enviar ao destino com o sendMessage. Além disto a mensagem criada pelo usuário precisa ser atualizada no banco de dados, através do método update e também atualizada na lista de mensagens da interface também com um método chamado update.

8

Figura 5 - Diagrama de sequência

2.2.2 Diagrama de Classe

O diagrama de classes apresentado na Figura 6 descreve os objetos e variáveis de cada classe, bem como seus métodos, os quais serão descritos a seguir.

9

Figura 6 - Diagrama de classes do InterProxy

UI

• MainActivity – Classe principal do aplicativo, responsável por gerenciar o fluxo inicial, apresentar os dados para o usuário e mostrar abas.

• RequestActivity – Responsável por gerenciar a aba Request.

• Response – Responsável por gerenciar a aba Response. Database

• DatabaseManager – Estabelece conexões com o banco e database.

• MessagesDAO – Recebe operações e as realiza no banco de dados. Server

• HomePageHandler – Responsável por receber, desempacotar, empacotar e enviar mensagens.

• WebServer – Thread encarregada de receber conexões e invocar o HomePageHandler

10

2.3 REQUISITOS

2.3.1 Requisitos Não-Funcionais

[RNF001] O sistema será desenvolvido em Android na versão 4.3 (Jelly Bean) [RNF002] O Sistema deverá possuir tolerância a falhas, no caso de force close usuário poderá retornar ao sistema normalmente. [RNF003] O dispositivo alvo será o tablet Android 10”. [RNF004] O banco de dados utilizado será o SQLite.

2.3.2 Requisitos Funcionais

Módulo Servidor [RF001] Aguardar conexões em uma determinada porta TCP. [RF002] Receber múltiplas conexões na porta. [RF003] Abrir uma mensagem HTTP e processar os dados. [RF004] Encaminhar as mensagens recebidas para o destino, sem modificação. [RF005] Bloquear uma mensagem recebida de modo a permitir que o usuário modifique seus dados e em seguida enviar a mensagem alterada para o seu destino. [RF006] Enviar para o módulo de banco de dados todas as mensagens HTTP de requisição e resposta. [RF007] Enviar para o módulo de banco de dados todas as mensagens HTTP de resposta cujo os MIME type sejam text, application e messages. Caso contrário, será armazenado apenas o cabeçalhos das mensagens.

Módulo Banco de Dados [RF008] Estabelecer conexão com o banco de dados. [RF009] Receber dados do módulo de servidor e armazená-los. [RF010] Receber as consultas dos módulos de servidor e interface gráfica e retornar os dados.

Módulo Interface

[RF011] Receber dados do módulo de banco de dados e apresentá-los na tela. [RF012] Permitir ao usuário habilitar/desabilitar opção de bloqueio de mensagens (intercept). [RF013] Permitir ao usuário modificar as mensagens bloqueadas. [RF014] Exibir um histórico de mensagens recebidas, essa lista deverá refletir as mensagens armazenadas no banco de dados.

11

[RF015] Ao selecionar uma mensagem no histórico, serão apresentados os dados de request/response da mensagem. [RF016] Permitir ao usuário descartar uma mensagem bloqueada.

12

3 TESTES E RESULTADOS

Nesta seção serão descritos os testes executados, os resultados esperados e os resultados obtidos, de modo a demonstrar as funcionalidades corretamente implementadas. Os testes serão agrupados de acordo com o módulo testado e seguirão uma ordem crescente de complexidade.

3.1 MÓDULO DE SERVIDOR

Quadro 1 - Testes do módulo de servidor

Caso de Teste Resultado Esperado Resultado Obtido

Verificar se o servidor pode ser iniciado e finalizado.

O servidor é iniciado e finalizado quando o botão é pressionado e a mensagem com o endereço e porta é mostrada na interface.

O servidor pode ser iniciado e finalizado utilizando o botão na interface.

O servidor é capaz de receber conexões e direcionar os dados ao módulo de banco de dados para armazenamento

Ao receber uma requisição a mesma é processada e tem o seu conteúdo apresentado no histórico da interface.

O servidor processou as requisições recebidas e direcionou as informações para armazenamento.

O servidor é capaz de bloquear requisições e apresentá-las ao usuário

Uma requisição interceptada é bloqueada e apresentada na aba Request para que o usuário visualize e edite a mesma.

A requição foi bloqueada e teve seu conteúdo apresentado para edição do usuário.

Uma requisição bloqueada pode ser enviada

Ao clicar no botão Forward com uma requisição bloqueada a mesma é enviada.

A requisição bloqueada foi enviada.

Uma requisição bloqueada pode ser descartada

Ao clicar no botão Drop com uma requisição bloqueada a mesma é descartada.

A requisição bloqueada foi descartada.

3.2 MÓDULO DE BANCO DE DADOS

Quadro 2 - Testes do módulo de banco de dados

Caso de Teste Resultado Esperado Resultado Obtido

As requisições e respostas enviadas pelo módulo de servidor são armazenadas.

Os dados são armazenados e a interface gráfica é capaz de apresentá-los.

O módulo de banco de dados armazena os dados corretamente.

Os dados armazenados são enviados à interface gráfica.

Os dados são apresentados na interface gráfica, seja no histórico quando nas abas de Request e Response

Os dados armazenados no banco são apresentados corretamente na interface gráfica.

A base de dados pode ter todas as entradas excluídas.

Ao clicar no botão “Clear History” todos os dados presentes na base são excluidos e o histórico apresenta-se

Os dados foram removidos e o histórico encontra-se vazio.

13

vazio..

3.3 INTERFACE GRÁFICA

Quadro 3 - Testes da interface gráfica

Caso de Teste Resultado Esperado Resultado Obtido

As requisições armazenada no banco de dados são apresentadas no histórico

A aplicação apresenta novas requisições no histórico.

As requisições foram apresentadas corretamente.

Ao selecionar uma requisição no histórico a mesma é apresentada na aba Request

A requisição selecionada é apresentada no aba Request.

A requisição selecionada foi apresentada na aba Request.

Uma requisição apresentada na aba Request pode ser editada

A requisição apresentada na aba Request foi editada.

A requisição apresentada na aba Request foi editada.

Ao selecionar uma requisição no histórico a resposta correspondente é apresentada na aba Response

A requisição selecionada tem sua resposta apresentada no aba Response.

A requisição selecionada tem sua resposta apresentada no aba Response.

14

4 CONCLUSÃO

Apesar da crescente evolução do mercado de dispositivos móveis e da área de segurança da informação ambas ainda não possuem uma boa interação. Portanto, a solução proposta visa estreitar esta relação ao facilitar a execução de testes de segurança em dispositivos móveis.

Para alcançar a solução proposta, foi desenvolvido uma aplicação para dispositivos móveis da plataforma Android adotando as definições apresentadas anteriormente. Cada um dos módulos foi implementado utilizando linguagem Java e o ambiente Android Studio, o qual simplificou as interações com o dispositivo físico e simulado durante a fase de testes.

Mesmo com a utilização de uma linguagem conhecida e um ambiente de desenvolvimento amigável diversos problemas foram encontrados. Entre eles os mais críticos envolveram a arquitetura de aplicações da plataforma Android, onde existem diversos tipos de componentes, activities, services, content providers e broadcast receivers. Por se tratar de uma aplicação que envolve atividades constantes com banco de dados e camada de rede, além da interface com o usuário, foi necessário utilizar todos estes componentes. Isto tornou a curva de aprendizagem muito longa, atrasando um pouco os resultados. Entretanto este problema foi gerenciado de maneira correta e não ocorreram impactos significativos na entrega do projeto.

Como propostas para projetos futuros podem ser indicadas o suporte a HTTPS e portabilidade para outras plataformas móveis como Apple (iOS) e Windows Phone. Com relação ao suporte HTTPS, o mesmo não foi disponibilizado nesta versão do sistema pois exige uma gerência de infraestrutura de certificados, mecanismo bastante complexo. O qual demandaria um esforço na implementação incompatível com a proposta deste projeto.

15

5 REFERÊNCIAS

[1] android.database. Android Reference. Disponível em:

http://developer.android.com/guide/topics/data/data-storage.html. Acesso em: 13 abr. 2014.

[2] OWASP 2013. The ten most critical web application security risk. Disponível em: http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202013.pdf. Acesso em: 09 jun. 2014.

[3] Paros Proxy. Disponível em http://www.parosproxy.org/index.shtml Acesso em: 09 jun. 2014.

[4] Burp Proxy. Disponível em http://portswigger.net/burp/proxy.html Acesso em: 09 jun. 2014.

[5] SOMMERVILLE. Engenharia de Software. 8ª Edição. 2008. [6] PRESSMAN, Roger S. Engenharia de Software – Uma abordagem

Profissional – Editora Bookman – Porto Alegres – RS – 2011. [7] KALRA, Gursev. Mobile Application Security Test. Disponível em:

http://www.mcafee.com/br/resources/white-papers/foundstone/wp-mobile-app-security-testing.pdf Acesso em: 09 jun. 2014.

[8] IBM. Undestanding Web application security challenges. Janeiro, 2008. Disponível: ftp://ftp.software.ibm.com/software/rational/web/whitepapers/r_wp_webappsecurity.pdf Acesso em: 09 jun. 2014.

[9] MCREE, Russ. Web application security testing 101: Paros Proxy and Badstore. ISSA Journal. Dezembro, 2006.

[10] BURNSIDE, M. et al. Proxy-Based Security Protocols in Networked Mobile Devices. MIT Laboratory for Computer Science. 2012.