Segurança de aplicativos móveis: Como garanti-la?

O que os atacantes procuram em nossos dispositivos móveis?

• Acesso a credenciais
• Dados pessoais (endereços, dados de cartão de crédito, localização…)
• Acessar o armazenamento de dados do aplicativo
• Realizar engenharia reversa para localizar vulnerabilidades, credenciais embutidas ou algoritmos que gerem chaves
• Instalação de malware ou bloqueio de funções existentes
• Acessar o dispositivo e controlar as conexões
• Etc.

Como podemos observar, dotar nosso aplicativo de mecanismos de segurança que impeçam a realização das ações anteriores se torna algo imprescindível.

Blindagem em aplicativos móveis: por que não é o habitual?

A principal razão é que os desenvolvedores enfatizam que estes funcionem corretamente em uma ampla gama de dispositivos, que cumpram todos os requisitos definidos… e focam-se sobretudo em aspectos mais atraentes para o usuário, como usabilidade, experiência do usuário e interface gráfica.

No entanto, o essencial é que sejamos conscientes de que implementar mecanismos de segurança em um aplicativo móvel é igualmente importante, especialmente considerando o grande volume de usuários que podem utilizá-lo.

De fato, cada vez mais empresas têm seus aplicativos passando por um processo de hacking ético, que tenta hackear um sistema para identificar e corrigir possíveis vulnerabilidades, prevenindo eficazmente a exploração por hackers maliciosos.

Medidas básicas de segurança para aplicativos móveis

Quando fizermos nosso desenvolvimento mobile, devemos focar em várias áreas e cumprir uma série de requisitos em cada uma delas. Para isso, podemos nos basear no padrão de segurança de aplicativos móveis OWASP, que se encarrega de prever requisitos para arquitetos e desenvolvedores de software que buscam desenvolver aplicativos móveis seguros.

Este guia define 2 níveis de verificação de segurança, assim como um conjunto de requisitos de resistência à engenharia reversa.

A escolha do nível dependerá do contexto de nossa aplicação. O nível L1 contém requisitos genéricos de segurança recomendados para todos os aplicativos móveis. O próximo nível, L2, está focado em apps que lidam com dados altamente sensíveis (setor financeiro, indústria da saúde).

A seguir, especificamos os requisitos de segurança mais notáveis que devemos levar em consideração no desenvolvimento de nossa aplicação, categorizados em sete áreas, embora possamos encontrar a lista completa no próprio guia OWASP:

Armazenamento de dados e privacidade

A proteção de dados sensíveis, como credenciais e informações privadas, é, além de um imperativo legal, um aspecto crítico na segurança móvel.

Alguns dos requisitos que permitem prevenir o acesso a essas informações são os seguintes:

• Não armazenar informações sensíveis no armazenamento local do dispositivo, e caso seja necessário, estas devem ser criptografadas usando uma chave derivada do hardware de armazenamento seguro, que requer autenticação prévia.
• Não escrever informações sensíveis nos logs do sistema nem em cópias de segurança.
• Não expor informações sensíveis como senhas ou números de cartão através da IU (interface do usuário) ou capturas de tela, e desativar o cache do teclado nos campos de texto que contêm essas informações.

Uso de chaves criptográficas

Na hora de proteger as informações sensíveis armazenadas em nosso dispositivo, a criptografia é um componente fundamental. Ao utilizar chaves criptográficas, devemos levar em consideração os seguintes requisitos:

• Não depender unicamente de criptografia simétrica cujas chaves estejam diretamente no código-fonte do app.
• Não reutilizar a mesma chave criptográfica para vários propósitos.
• Os valores aleatórios são gerados utilizando um gerador de números aleatórios suficientemente seguro.

Autenticação e controle de sessões

Para que um aplicativo seja seguro, deve contar com um mecanismo de autenticação e controle da sessão do usuário. Embora seja verdade que a maioria dessa lógica se encontra no lado do servidor, a seguir indicamos alguns requisitos que devemos ter em conta:

• A autenticação biométrica, se houver, não está associada a eventos (por exemplo, usando uma API que simplesmente retorna “true” ou “false”), mas sim baseada no desbloqueio do keychain/keystore (armazenamento seguro).
• Para aplicações que gerenciam informações muito sensíveis, aplicar mecanismos de autenticação de dois fatores.
• As sessões e os tokens devem expirar após um tempo predefinido de inatividade por parte do usuário.

Comunicação com serviços

Um aspecto importante nos aplicativos é garantir a segurança na comunicação com o servidor, assegurando a confidencialidade e integridade dos dados trocados. Para isso, alguns requisitos são:

• As informações são enviadas criptografadas utilizando o protocolo TLS.
• O aplicativo verifica o certificado X.509 do sistema remoto ao estabelecer o canal seguro e apenas são aceitos certificados assinados por uma CA confiável.
• O aplicativo utiliza seu próprio armazenamento de certificados ou realiza pinagem do certificado ou da chave pública do servidor.

Interação com a plataforma móvel

A interação entre os aplicativos e os sistemas operacionais deve ser realizada levando em consideração os seguintes aspectos:

• O aplicativo requer a quantidade mínima necessária de permissões.
• O aplicativo não expõe nenhuma funcionalidade sensível através de mecanismos IPC a menos que esses mecanismos estejam devidamente protegidos
• Desabilitar JavaScript dos Webviews a menos que seja necessário.
• As WebViews são configuradas para permitir o mínimo de esquemas (idealmente, apenas https). Esquemas perigosos como file, tel e app-id estão desabilitados.

Qualidade do código

Apesar de que os aplicativos não são tão vulneráveis a ataques do tipo Cross-Site Scripting, os desenvolvedores devem seguir um guia de boas práticas para que o código seja seguro:

• O aplicativo deve ser assinado e fornecido com um certificado válido, assim como ser publicado em modo release.
• O aplicativo captura e gerencia devidamente as possíveis exceções.
• As funcionalidades de segurança gratuitas das ferramentas, tais como minificação do byte-code, proteção da pilha, suporte PIE e contagem automática de referências, estão ativadas.
• Fazer uso de ferramentas que permitam analisar o código-fonte para detectar possíveis vulnerabilidades como, por exemplo, SonarQube.

Mecanismos contra a manipulação e engenharia reversa

Devemos evitar que um atacante possa manipular nossa aplicação ou realizar a engenharia reversa do código. Para isso, existem vários mecanismos que devem ser implementados:

• Assinatura do aplicativo: Uma das técnicas de segurança mais importantes no Android é a assinatura dos aplicativos utilizando chaves públicas e privadas.

Ao compilar um aplicativo com todos os elementos que o compõem (textos, gráficos, código...) cada desenvolvedor deve assegurá-lo com seu certificado para que a assinatura identifique o aplicativo e seja possível saber se foi modificado ou se mantém intacto. Esta é a única maneira de saber se um app é falso ou autêntico: no caso de ter sido modificada a assinatura, se houver, não corresponderá ao desenvolvedor original.

• Anti-Tamper: As técnicas anti-tamper dificultam que um atacante possa modificar um software, realizando engenharia reversa e validando sua integridade para seu uso posterior modificado. Para isso, verifica-se que a assinatura do aplicativo seja a original e aplicam-se mecanismos de verificação do checksum.
• Ofuscação do código: A ofuscação do código permite compactar, otimizar e tornar o código ilegível, renomeando semanticamente classes, campos, métodos e nomes. O resultado é um aplicativo menor e mais complexo de realizar engenharia reversa sobre ele, dificultando a compreensão dos mesmos para olhos maliciosos.
• Verificação da origem do instalador: Com esta técnica, verifica-se que o aplicativo foi distribuído a partir de uma fonte confiável, evitando que tenhamos em nosso terminal uma cópia do apk que possa ter sido infectada com malware.
• Anti-Debug: As técnicas anti-debug dificultam ou detectam a depuração de um aplicativo, com o objetivo de aplicar determinadas ações que evitem que um atacante continue com o processo. O mecanismo mais simples é através de uma propriedade no próprio manifesto do app, embora se recomende verificar dinamicamente e em vários pontos se a depuração está ocorrendo ou não.
• Anti-Emulador: Se nosso aplicativo estiver sendo executado em um emulador fora do processo de desenvolvimento, isso indica que alguém além de nós está tentando analisar o aplicativo. Portanto, uma boa prática é verificar que, em uma versão release, o aplicativo não está sendo acessado por meio de um emulador que facilite atacar sua segurança.
• Anti-Root: Deve-se evitar sempre que possível que um aplicativo seja executado em terminais rooteados, dado que são terminais muito mais vulneráveis e que permitem acesso à memória reservada do sistema e do aplicativo, comprometendo a persistência e, portanto, a privacidade dos dados que são manipulados.
• Anti-Clone: mecanismo para evitar que o aplicativo possa ser clonado, a este respeito serão definidas as propriedades adequadas para evitar fazer uma cópia do aplicativo instalado e obter o binário que um possível atacante poderia utilizar para aplicar técnicas de engenharia reversa.
• Dispositivo confiável: O Google possui uma API anti-abuso (SafetyNet Attestation API), que permite avaliar se o dispositivo Android em que um aplicativo está sendo executado é confiável.

Conclusão

Cada dia fazemos uso de mais aplicativos móveis e cada vez estes armazenam uma maior quantidade de informações sensíveis do usuário. Por isso, é muito importante estar atualizado sobre novas medidas de segurança que vão surgindo, e aplicá-las de maneira proativa em nossos desenvolvimentos. O objetivo não deve ser apenas que o usuário interaja com uma boa UX, mas também que o faça com total segurança.

“Estar ciente das vulnerabilidades já é metade da segurança”.