Segurança no desenvolvimento móvel: o que é, quais ameaças existem e como se defender

Principais Ameaças: OWASP Mobile Top 10

O que é OWASP Mobile Top 10?

OWASP (Open Web Application Security Project) é uma organização sem fins lucrativos que publica um ranking das vulnerabilidades de segurança móvel mais perigosas. OWASP Mobile Top 10 é uma lista que ajuda os desenvolvedores a entender no que focar primeiro. Na versão 2024, problemas relacionados a armazenamento inseguro, autenticação fraca e comunicação de rede insegura lideram o ranking.

M1: Armazenamento Inseguro de Dados — o problema mais comum: senhas, tokens e dados pessoais permanecem em SharedPreferences, NSUserDefaults ou arquivos locais sem criptografia. M2: Autenticação Fraca — falta de verificação no lado do servidor, senhas fracas. M3: Comunicação de Rede Insegura — falta de HTTPS ou verificação incorreta do certificado SSL. M4 e M5 estão relacionados a criptografia e uso incorreto de API.

M6: Autorização Insegura — um usuário pode acessar dados de outro usuário substituindo um ID em uma requisição. M7: Injeção de Código (SQL Injection, XSS). M8: Manipulação do Aplicativo — reempacotamento, substituição de código. M9 e M10 — vazamento de dados através de bibliotecas de terceiros e engenharia reversa. Para cada uma dessas ameaças existem contramedidas comprovadas, e na IT Sectr as aplicamos em todos os projetos desde 2017.

Ataques Man-in-the-Middle (MITM)

O ataque MITM ocorre quando um atacante intercepta o tráfego entre o aplicativo e o servidor. Isso é possível através de falsificação de DNS, ARP spoofing ou conexão a uma rede Wi-Fi não segura. Certificados SSL/TLS e Certificate Pinning são usados para proteção.

Certificate Pinning é um mecanismo onde o aplicativo verifica se o certificado do servidor corresponde a um pré-armazenado no código do aplicativo. Mesmo que um atacante substitua o certificado através de um proxy (por exemplo, Burp Suite), o aplicativo rejeitará a conexão. O Pinning é de dois tipos: Public Key Pinning e Certificate Hash Pinning.

Criptografia e Hashing: AES, RSA, SSL/TLS

Criptografia Simétrica: AES

AES (Advanced Encryption Standard) é um algoritmo de criptografia simétrica, a base da segurança de dados no dispositivo. AES usa a mesma chave para criptografar e descriptografar dados. AES suporta chaves de 128, 192 ou 256 bits. No desenvolvimento móvel, AES-256 é usado para criptografar dados no dispositivo: arquivos, cache, registros no banco de dados local.

Modos AES: GCM (recomendado) — fornece autenticação de dados, CBC — modo básico com encadeamento de blocos, ECB — inseguro, não use. Para iOS, AES está disponível através de CommonCrypto (CCOptions), para Android — através de Cipher no Java Cryptography Architecture (JCA). Importante: a chave de criptografia nunca deve ser armazenada no código do aplicativo — use Keychain/Keystore.

Criptografia Assimétrica: RSA — usa um par de chaves (pública e privada). RSA é usado para criptografar pequenas quantidades de dados — tipicamente para trocar uma chave simétrica entre cliente e servidor. O comprimento mínimo da chave RSA é 2048 bits (4096 recomendado). No iOS, RSA está disponível através do Security Framework (SecKeyCreateRandomKey), no Android — através de KeyPairGenerator no Android Keystore.

Hashing e SSL/TLS

Hashing (SHA-256, SHA-3) é uma transformação irreversível de dados em uma string de comprimento fixo. Hashes são usados para verificação de integridade de dados e armazenamento de senhas. Para senhas, use obrigatoriamente bcrypt, scrypt ou Argon2 — SHA-256 simples é vulnerável a ataques de tabela rainbow. SSL/TLS é um protocolo para criptografar o tráfego de rede entre cliente e servidor. O padrão moderno é TLS 1.3, que fornece Perfect Forward Secrecy (PFS).

TLS 1.3 é mais rápido que seus antecessores: o handshake leva uma ida e volta em vez de duas. No Android, a versão mínima do TLS é configurada através de SSLSocket, no iOS — através de ATS (App Transport Security), que por padrão exige TLS 1.2 ou superior. ATS só pode ser desabilitado para domínios específicos com justificativa.

Armazenamento Seguro: Keychain e Keystore

iOS: Keychain

Keychain é um armazenamento seguro no iOS / macOS para senhas, chaves de criptografia, certificados e tokens. Os dados no Keychain são criptografados com uma chave de hardware única para cada dispositivo. O acesso ao Keychain é controlado através do Security Framework (SecItemAdd, SecItemCopyMatching). O Keychain é bloqueado automaticamente quando o dispositivo é bloqueado e é criptografado usando o Secure Enclave.

Android: Keystore

Android Keystore é um armazenamento de sistema para chaves criptográficas, isolado do aplicativo. A partir do Android 6.0 (API 23), o Keystore usa suporte de hardware (TEE — Trusted Execution Environment) em dispositivos com chip de segurança. As chaves no Keystore nunca saem da área segura — o aplicativo recebe apenas um handle para operações de criptografia e assinatura.

SharedPreferences e NSUserDefaults não foram projetados para armazenar dados sensíveis — eles armazenam informações em texto simples. Para proteção de dados, use EncryptedSharedPreferences (Android) ou criptografe os dados antes de salvar no UserDefaults (iOS). Na IT Sectr, sempre usamos Keychain e Keystore para tokens de acesso e senhas.

Autenticação: OAuth 2.0, JWT e Biometria

OAuth 2.0 e OpenID Connect

OAuth 2.0 é um protocolo de autorização delegada que fornece acesso seguro aos recursos do usuário sem transmitir a senha. Em aplicativos móveis, o fluxo Authorization Code com PKCE (Proof Key for Code Exchange) é o mais comumente usado. PKCE impede a interceptação do código de autorização — um requisito obrigatório para aplicativos móveis.

OpenID Connect (OIDC) é uma extensão sobre OAuth 2.0 para autenticação de usuário. OIDC adiciona um ID Token no formato JWT que contém informações do usuário (nome, email, id). O fluxo OAuth 2.0 + OIDC inclui: redirecionar o usuário para a página de login, obter um código de autorização, trocar o código por tokens (access + refresh + id), usar o token de acesso para requisições de API.

JWT: Tokens de Acesso, Atualização e Sessão

JWT (JSON Web Token) é um formato de token compacto e seguro para URL que contém claims em formato JSON. JWT consiste em três partes: header (tipo e algoritmo de assinatura), payload (dados) e signature (assinatura). O Token de Acesso é um token de curta duração (15–60 minutos) para acesso à API. O Token de Atualização é um token de longa duração (dias/semanas) para obter um novo token de acesso sem novo login.

Token de Sessão é uma abordagem tradicional onde o servidor armazena a sessão em um banco de dados ou Redis, e o cliente recebe um identificador aleatório. No desenvolvimento móvel, JWT é preferível: não requer armazenamento de sessão no lado do servidor, contém todas as informações dentro de si e é fácil de verificar. No entanto, JWT não pode ser revogado instantaneamente — este é um compromisso que é resolvido com um tempo de vida curto do token de acesso e o uso de tokens de atualização.

Autenticação Biométrica

Face ID e Touch ID no iOS, Autenticação por Impressão Digital no Android — métodos de autenticação biométrica que usam características físicas únicas do usuário. No iOS, a biometria funciona através de LocalAuthentication (LAContext), no Android — através de BiometricPrompt (Android 9+) ou FingerprintManager (obsoleto). A biometria é usada para desbloquear o aplicativo, confirmar pagamentos e acessar dados protegidos.

Nuances importantes: a biometria é uma UX conveniente, mas não substitui a autenticação do servidor. Após a verificação biométrica bem-sucedida, o aplicativo deve obter um token de acesso do servidor. No Android, certifique-se de verificar que o dispositivo usa biometria Classe 3 (Forte), não apenas reconhecimento facial baseado em câmera (Classe 1).

Proteção de Código: ProGuard, R8 e Root Detection

Ofuscação: ProGuard e R8

ProGuard é uma ferramenta de ofuscação, compressão e otimização de bytecode Java para Android, aumentando a segurança do código contra engenharia reversa. R8 é seu sucessor, integrado ao Gradle desde o Android Studio 3.4. O R8 realiza quatro tarefas: compressão (remove classes e métodos não utilizados), otimização (inline métodos, simplifica código), ofuscação (renomeia classes e métodos para nomes curtos) e pré-verificação (verificação de bytecode).

DexGuard é uma versão comercial do ProGuard com proteção aprimorada: criptografia de strings, ofuscação de recursos, proteção contra reempacotamento, controle de integridade APK. Para a maioria dos projetos, R8 é suficiente, mas para aplicações financeiras e bancárias, DexGuard fornece uma camada adicional de segurança. R8 é ativado através de build.gradle: minifyEnabled = true e proguardFiles.

Detecção de Root e Jailbreak

Root Detection (Android) e Jailbreak Detection (iOS) são mecanismos que verificam se privilégios de superusuário foram obtidos no dispositivo. Em dispositivos comprometidos, é possível ler a memória do processo, interceptar tráfego e substituir código. Para verificação no Android, usa-se a presença do binário SU, chaves de assinatura de teste e flags de compilação não padrão.

RASP (Runtime Application Self-Protection) é uma tecnologia que protege o aplicativo durante a execução. RASP detecta tentativas de depuração, reempacotamento, injeção de código e encerra o aplicativo quando ameaças são detectadas. Exemplos de soluções RASP: Dexter, Guardsquare, Promon. RASP funciona em tempo de execução e reage a anomalias — ao contrário da ofuscação estática, que protege o código antes da execução.

Engenharia Reversa é o processo de recuperar o código-fonte a partir de um aplicativo compilado. Ferramentas: JADX (decompilador APK), Ghidra, IDA Pro, Hopper. A proteção contra Engenharia Reversa é uma combinação de ofuscação, criptografia de strings, verificação de integridade e Root Detection. Não existe proteção completa — o objetivo é tornar a engenharia reversa cara o suficiente para o atacante.