Desenvolvendo aplicativos mobile de forma segura.

Matheus Bolela
luizalabs
Published in
10 min readJul 16, 2020

Algumas dicas para você que é desenvolvedor mobile adotar, durante o desenvolvimento de seus app’s.

Embora seja necessário levar em consideração a segurança do usuário na hora de desenvolver aplicativos, mesmo que ambas as plataformas abordadas (iOS e Android) deem suporte, o desenvolvedor precisa estar atento a medidas adotadas no código. As inúmeras notícias de vazamento mostram que os códigos entregues apresentam brechas.

Análise de riscos em regras de negócio.

Vamos começar pela fase de discovery, no momento que a equipe ainda está pensando em como entregar um produto legal ao cliente ou a área de negócio solicitante.

Por acaso já pensou em fazer uma análise de risco nas regras de negócio ?

Pensou que pode existir riscos a serem mitigados ainda na fase de planejamento ?

Pois então está na hora de exercitar, vamos ao exemplo:

Exemplo: Joãozinho e sua squad recebem uma demanda referente ao desenvolvimento de um jogo mobile no estilo Pokémon Go, onde os usuários do aplicativo ganhariam uma porcentagem de desconto em algum produto ou serviço a cada KM percorrido com seu personagem. Joãozinho começa então a analisar possíveis riscos em uma regra de negócio específica, o KM percorrido:

Risco 1- Se a cada KM percorrido o usuário ganha um percentual de desconto, é importante colocar um limite de velocidade para cada tipo de exercício praticado, pois assim o usuário não teria como burlar o aplicativo para ganhar KM’s apenas pegando carona no Uber.

Risco 2- Caso o usuário ainda consiga burlar o limite de velocidade seria legal implementar um limite de KM’s por dia, assim o usuário não abusaria de uma possível falha.

Risco 3- É importante que seja implementado um controle de contas de usuário através do número do chip do smartphone, assim evitaria que usuários mal intencionados utilizem outra conta (fake), após o limite diário de sua conta oficial terminar.

Podemos ver que em pouco tempo, Joãozinho conseguiu identificar três riscos que poderiam causar prejuízos, trazer retrabalho ou até colocar o aplicativo em cheque.

Uso da plataforma

As plataformas iOS e Android fornecem recursos de segurança bem documentados e apontam boas práticas que devem ser seguidas. Você pode ter acesso a elas pelos seguintes links:

Android:

https://developer.android.com/topic/security/best-practices
https://source.android.com/security/

iOS:

https://developer.apple.com/documentation/security

Tráfego criptografado

Criptografar o tráfego de dados é o passo inicial para manter seu aplicativo seguro de vazamento de informações, por tanto, habilite o protocolo HTTPS juntamente com o protocolo TLS (Transport Layer Security) em sua versão 1.2 ou 1.3 em todos os componentes de seu aplicativo seja uma webview ou em suas API’s, as versões TLS 1.0 e 1.1 já estão depreciadas por isso não é recomendado implementá-las. Um ataque muito comum em endpoints sem a presença do HTTPS é o MITM (Man in the middle), que funciona da seguinte forma: como o endpoint não se encontra criptografado, fica possível interceptá-lo e capturar dados em texto plano.

Caso queira testar se o endpoint está com o TLS configurado de forma correta, você pode utilizar o SSL Server Test:

https://www.ssllabs.com/ssltest/

Imagem 1: Exemplo de ataque MITM a aplicativo mobile.

Certificate and Public Key Pinning

Para habilitar o protocolo HTTPS, você precisará de um certificado digital, que é utilizado para realizar a autenticação entre cliente e servidor, garantindo assim a autenticidade da conexão. Com tudo para combater ataques como o já mencionado MITM é necessário também realizar a pinagem do certificado digital ou da chave pública no código fonte, assim caso o smartphone do cliente venha a ser comprometido por um atacante, será praticamente inviável descriptografar o tráfego interceptado na comunicação entre o smartphone e o servidor do aplicativo para roubar os dados.

Tipos de Fixação de Certificado SSL

Existem duas opções de fixação do certificado:

  • Fixar o próprio certificado: você pode baixar o certificado do servidor e fixá-lo no seu aplicativo. Em tempo de execução, o aplicativo compara o certificado do servidor ao que você incorporou.
  • Fixar a chave pública: você pode recuperar a chave pública do certificado e incluí-la no seu código como uma sequência. Em tempo de execução, o aplicativo compara a chave pública do certificado com a codificada no código.

A escolha entre essas duas opções depende das suas necessidades e da configuração do servidor. Se você escolher a primeira opção, precisará fazer uma atualização de seu aplicativo quando seu certificado expirar ou ele parar de funcionar. Se você escolher a segunda opção, ela poderá violar a política de rotação de chaves porque a chave pública não muda, além disso é importante manter um backup de um novo certificado caso o certificado com a chave privada seja exposto.

Abaixo fica a sugestão de bibliotecas que podem ajudar a implementar a fixação do certificado:

Android: https://github.com/datatheorem/TrustKit-Android
iOS: https://github.com/datatheorem/trustkit

Autenticação

Este é um item que você não deve de maneira alguma reinventar a roda, ou seja, você não precisa criar mecanismos de autenticação seguros do zero, porque além de dar muito trabalho, pode não ficar 100% seguro e comprometer a segurança do aplicativo.

Portanto a sugestão aqui é utilizar plataformas de autenticação SSO (Single Sign-on), pois elas são mantidas por empresas de nicho e caso alguma vulnerabilidade surja, com certeza alguma atualização será disponibilizada a tempo. Além disso, esse tipo de plataforma possui alguns itens de segurança que são essenciais, como trabalhar com protocolos de autenticação seguros (OAuth, SAML ou OpenID), autenticação delegada (Facebook, Google e etc), 2FA (Duplo fator de autenticação), política de senhas, gerenciamento de sessão, gerenciamento de usuários e etc.

O ganho que as plataformas de SSO trazem vão muito além da segurança, elas trazem redução do esforço de desenvolvimento e facilidade aos usuários, devido ao fato de que o usuário terá apenas um login para se autenticar em dezenas de outras aplicações, desde de que estejam integradas ao servidor de SSO.

Abaixo estão duas sugestões open source de plataformas de SSO:

CAS: https://apereo.github.io/cas/4.2.x/index.html
Keycloak: https://www.keycloak.org/

Validação de input e output

Grande parte das vulnerabilidades podem ser mitigadas através da validação de input e output, por esse motivo é importante rejeitar input de dados inválidos, ao invés de tentar checar se os dados são realmente válidos.

Caso algum caractere potencialmente perigoso precise ser permitido no input de dados, certifique-se de utilizar mecanismos adicionais como a criação de uma white list, utilizar alguma regex e criar uma trilha de auditoria dos dados. Exemplos de caracteres potencialmente perigosos: < = > “ ‘ % & + \ *.

Outro ponto extremamente importante é validar dados provenientes de redirecionamentos, pois é possível incluir conteúdo malicioso diretamente para o alvo do redirecionamento, podendo assim contornar a lógica do aplicativo e qualquer validação executada antes do redirecionamento.

Armazenamento de dados

O elo mais fraco sempre será o smartphone do usuário, portanto pense duas vezes antes de armazenar qualquer tipo de dado sensível no dispositivo, faça isso somente em último caso, pois a possibilidade de que o usuário tenha configurado seu mobile para ser utilizado em modo ROOT ou possua JailBreak e tenha seu dispositivo comprometido é grande.

Lembre-se que dados armazenados localmente no dispositivo podem ser acessados por outros aplicativos.

Criptografia

Sempre que dados sensíveis forem armazenados na memória do dispositivo, no cartão SD, em arquivos de cache, ou transmitidos via API, eles devem ser criptografados, para inibir que outros aplicativos ou agentes maliciosos obtenham acessos aos dados.

Procure utilizar criptografias fortes como AES-256 ou SHA-2, pois essas ainda não possuem relatos de vulnerabilidades que indiquem ser possível quebrá-las de alguma maneira. De modo algum utilize hashs MD5 ou SHA1, pois em ambas existe a possibilidade de ataques de colisão de hash, o que poderia revelar o dado criptografado.

Alguns cuidados devem ser tomados com as chaves de criptografia, não inclua as chaves de criptografia no mesmo diretório onde se encontra o conteúdo criptografado, além disso não disponibilize as chaves de criptografia no seu binário.

Além dos dados pessoais de usuários também é importantíssimo criptografar dados referentes ao ambiente do aplicativo como API_KEYS, tokens, senhas, endpoints e dados de código SQL presentes no código fonte do aplicativo, já realizei diversas análises em aplicativos terceiros e em quase todos é possivel identificar dados como os citados acima expostos sem criptografia, isso facilita e muito a ação de agentes maliciosos na tentativa de roubo de dados e informações.

Imagem 2: Exemplo de comandos SQL não criptografados.

Tratamento de erros e logs

Os logs são extremamente importantes para resolução de incidentes de segurança e auditoria, por isso a ideia é criar logs de qualidade e não uma quantidade excessiva de logs desnecessários; além disso, o tratamento de erros é essencial para evitar vazamento de informações sistêmicas e dicas para usuários hostis.

Em respostas de erro procure não dar dicas, não informe detalhes do aplicativo, identificadores de sessão ou informações da conta do usuário, prefira retornar mensagens de erro genéricas, por exemplo, em vez de retornar em uma mensagem “Login inválido”, retorne “login ou senha inválidos” assim um atacante não saberia quais dos dados se encontram inválidos.

Aqui vai uma sugestão de logs para se gerar:

Cabeçalho X-Forwarded-For, username, IP, user agent e hora do evento.

O cabeçalho X-Forwarded-For possui o IP original do usuário que está logado no aplicativo, o username possui o login do usuário que realizou a ação, o IP pode indicar de qual proxy veio a requisição por exemplo, o user agent de qual sistema operacional, navegador e versão o usuário estava realizando tal ação e por fim a hora do evento é de suma importância para registro dos fatos.

Registre informações de usuários que realizaram alterações, atualizações e exclusões em sua aplicação, sejam elas de qualquer natureza, informações de autenticação sejam elas bem sucedidas ou não, parâmetros inválidos inseridos em entradas de dados, tentativas de chamadas a sua aplicação com tokens inválidos e etc.

Não logar
Não registre informações sensíveis em log, como dados de cartão de crédito, nome completo, CPF, endereço, telefone, ID de seção, tokens, senhas, caminhos de arquivos, domínios e subdomínios, nomes de buckets, IPs e redes privadas.

Engenharia reversa

Aplicativos mobile estão suscetíveis a engenharia reversa, porém existem alguns controles para dificultar que curiosos baixem o .APK ou .IPA de seu aplicativo, e acessem o código fonte obtendo toda sua lógica ou até mesmo o clonem.

Faça a ofuscação do código fonte, a qual realiza a alteração automática de nomes de classes, métodos, interfaces, atributos e etc, dando a eles novos e menores rótulos removendo assim a fácil compreensão da lógica e do algorítimo. Após a ofuscação ficará nítido todo o embaralhamento que sofreu o seu código.

Para aplicativos Android temos o famoso Proguard que é uma ferramenta open source e além de realizar a ofuscação, elimina código “morto”, ou seja, código que não é utilizado mais pelo aplicativo.

Proguard: https://www.guardsquare.com/en/products/proguard

Já para aplicativos iOS, temos o iXGuard, que basicamente funciona da mesma maneira que o Proguard, porém para ter acesso é necessário adquiri-lo

iXGuard: https://www.guardsquare.com/pt-br/produtos/ixguard

O aplicativo também deve identificar se o mobile possui algum mecanismo de JailBreak ou, no caso do Android, se está em modo ROOT. Caso seja identificado, deve-se automaticamente encerrar o aplicativo e imediatamente, a fim de evitar maiores danos. É dessa forma que o aplicativo deve se comportar caso seja executado em algum emulador, ou detecte a presença de alguma ferramenta de engenharia reversa como Ghidra, Frida, IDA Pro ou Hopper.

O RASP (Runtime Application Self-Protection) pode ajudar em alguns desses quesitos, o RASP, ferramenta que é integrada ou construída dentro do ambiente de tempo de execução de um aplicativo, permite que seu aplicativo monitore sua própria integridade e a integridade do dispositivo no qual está executando e reaja a ameaças em potencial. Infelizmente, a maioria dessas ferramentas não são gratuitas.

RASP: https://www.guardsquare.com/en/mobile-application-protection/runtime-application-self-protection-rasp

Teste a segurança de seu aplicativo

Não adianta implementar todos esses controles e não saber se realmente o aplicativo se encontra seguro, portanto, recomendo utilizar o MobSF (Mobile Security Framework) para realizar uma análise estática de seu aplicativo, o MobSF faz um code review automático e gera um relatório de vulnerabilidades, pontos de exposição de dados sensíveis, se a ofuscação do código está implementada de forma correta, permissões de acesso inadequadas e muitas outras coisas que podem ajudar a testar e melhorar a segurança de seu aplicativo.

O MobSF é open source, desenvolvido na linguagem python e foi criado por especialistas em segurança indianos, além da análise estática também possui a opção da análise dinâmica (quando é possivel interagir com o aplicativo através de um emulador).

MobSF: https://github.com/MobSF/Mobile-Security-Framework-MobSF

Outras dicas

Com a nova lei geral de proteção de dados (LGPD) batendo na porta, fique atento aos dados sensíveis, não permita que seja tirado print screen de telas onde contém dados sensíveis como números de cartão de crédito, CVV, CPF, nome e endereços completos, mascare esses tipos de dados para que não seja preciso mostrá-los totalmente, tanto para o próprio usuário, quanto para um funcionário da empresa ou desenvolvedor.

Garanta que o teclado do sistema operacional seja utilizado, teclados personalizados podem ser utilizados por atacantes para capturar os dados digitados.

Não exponha serviços desnecessariamente para a internet. Sempre que um serviço precisar ser exposto, utilize mais de um meio de autenticação no acesso, e caso precise acessar algum serviço fora das dependências de sua empresa, utilize uma VPN.

Por fim…

Essas foram algumas dicas, que se aplicadas podem trazer inúmeros benefícios para a segurança de seu aplicativo e seus usuários. Os atacantes estão cada vez mais motivados a roubar dados, porque esses podem valer uma fortuna no mercado negro. Portanto, garantir a proteção dos dados que trafegam pelo seu aplicativo é primordial.

Referências:

OWASP: O OWASP, ou Projeto Aberto de Segurança em Aplicações, é uma comunidade online que cria e disponibiliza de forma gratuita artigos, metodologias, documentações, ferramentas e tecnologias no campo de segurança de aplicações.

OWASP Mobile: https://owasp.org/www-project-mobile-top-10/
OWASP MASVS: https://github.com/OWASP/owasp-masvs/tree/master/Document
OWASP MSTG: https://owasp.org/www-project-mobile-security-testing-guide/

--

--

Matheus Bolela
luizalabs

Information Security Analyst & Security Researcher