Code Injection em aplicativos móveis — o que é, tipos de ataques e proteção

O que é Code Injection?

Code Injection é uma classe de ataques na qual um invasor injeta código executável em um aplicativo através de dados de entrada não confiáveis. Em aplicativos móveis, o ataque é possível através de campos de entrada, deep links, notificações push, códigos QR e troca de arquivos.

Ao contrário de ataques a nível de sistema operacional, o Code Injection explora erros lógicos no código do próprio aplicativo: falta de escape, concatenação insegura de strings ou confiança em fontes de dados externas. De acordo com um relatório da Positive Technologies (2025), as injeções representam 23% de todas as vulnerabilidades em aplicativos móveis do setor financeiro.

O principal perigo do Code Injection é o comprometimento total dos dados: um invasor pode obter acesso ao banco de dados, ao sistema de arquivos do dispositivo ou às contas de outros usuários. Para aplicativos móveis que lidam com dados de pagamento ou informações médicas, as consequências podem ser críticas.

Os desenvolvedores precisam entender os tipos de injeções e aplicar mecanismos de proteção em todos os níveis — desde a entrada de dados até a exibição e armazenamento. Os frameworks modernos fornecem ferramentas de segurança integradas, mas seu uso requer uma abordagem consciente.

Principais tipos de Code Injection em aplicativos móveis

A classificação de Code Injection inclui três tipos principais de ataques no contexto do desenvolvimento móvel. Cada tipo explora diferentes componentes do aplicativo e requer métodos de proteção específicos.

SQL Injection em aplicativos móveis

SQL Injection (SQLi) é a injeção de código SQL malicioso através de parâmetros de consulta para um banco de dados local ou remoto. Em aplicativos móveis, a vulnerabilidade surge ao trabalhar de forma insegura com SQLite no dispositivo ou ao construir requisições HTTP para uma API REST com concatenação de strings.

Um vetor de ataque típico é um campo de busca ou filtro cujo valor é diretamente substituído em uma consulta SQL. Se o desenvolvedor usar concatenação direta em vez de consultas parametrizadas, um invasor pode passar uma string como 1' OR '1'='1. De acordo com OWASP Mobile Top 10 (2024), o SQL Injection continua sendo a segunda vulnerabilidade crítica mais frequente em aplicativos móveis na categoria de armazenamento inseguro de dados.

A proteção contra SQLi é construída em três níveis: uso de consultas parametrizadas (PreparedStatement em Java, rawQuery com bindArgs no Android), validação de entrada no lado do cliente e servidor e privilégios mínimos de banco de dados.

Cross-Site Scripting (XSS) no WebView

Os ataques XSS em aplicativos móveis visam o componente WebView — um navegador incorporado que exibe conteúdo HTML. Se um aplicativo carregar dados de fontes externas no WebView sem sanitização, um invasor pode injetar código JavaScript que é executado no contexto do aplicativo.

Existem dois subtipos de XSS: XSS Armazenado — o script malicioso é salvo no servidor e executado em cada visualização de página, e XSS Refletido — o código é passado através de URL ou parâmetros POST e executado uma vez. Em aplicativos móveis, o XSS Armazenado através de comentários, avaliações ou conteúdo do usuário exibido no WebView para outros usuários é particularmente perigoso.

A proteção inclui desabilitar JavaScript no WebView se não for necessário, usar Content Security Policy (CSP) e sanitizar o conteúdo HTML através de bibliotecas como Jsoup para Android ou SwiftSoup para iOS.

Command Injection através de Intent e Shell

Command Injection é a execução de comandos do sistema no dispositivo através de chamadas não sanitizadas para Runtime.exec(), ProcessBuilder ou NSTask. Em aplicativos móveis, o ataque é possível se o aplicativo passar dados do usuário para comandos shell ou Intents com ações.

As áreas mais vulneráveis são funções de conversão de arquivos, processamento de mídia (ffmpeg, ImageMagick) e instalação de bibliotecas de terceiros. Um invasor pode passar um comando com um caractere de pipe ou redirecionamento que executa código arbitrário no dispositivo. Android restringe parcialmente o acesso shell através do sandbox, mas aplicativos com acesso root ou explorações de PrivEsc podem ser comprometidos.

A proteção recomendada é a rejeição completa de Runtime.exec() para processar dados do usuário, uso de bibliotecas com uma API segura e isolamento rigoroso de processos externos.

Como a injeção de código funciona no Android e iOS

O mecanismo de Code Injection difere nas plataformas Android e iOS devido a diferenças arquiteturais. No Android, as injeções são frequentemente associadas ao Intent — uma mensagem do sistema que é passada entre componentes do aplicativo. Um invasor pode enviar um Intent malicioso com dados extras contendo código SQL ou comandos shell.

No iOS, os ataques ocorrem mais frequentemente através do mecanismo de Comunicação Interprocessos (XPC), Universal Links e manipulação de URL Scheme. Um aplicativo que aceita dados de fontes externas sem validação torna-se vulnerável a injeções. De acordo com Apple Security Research (2025), cerca de 12% das vulnerabilidades em aplicativos iOS estão relacionadas à sanitização insuficiente de dados de entrada.

Um vetor comum para ambas as plataformas é o ataque através do armazenamento local (SQLite, Realm, UserDefaults). Se um aplicativo malicioso puder escrever dados em um diretório compartilhado, ele pode injetar código que será executado pelo aplicativo alvo ao ser lido.

Um processo de ataque típico inclui três estágios: reconhecimento — análise dos pontos de entrada do aplicativo (formulários, deep links, arquivos), injeção — entrega da carga maliciosa através do ponto de entrada encontrado, e exploração — execução da injeção para obter acesso a dados ou funcionalidades. Compreender esse ciclo ajuda os desenvolvedores a projetar proteção em cada estágio.

Exemplos de código: implementações vulneráveis e seguras

Vamos ver exemplos específicos de Code Injection em Kotlin para Android e Swift para iOS. Cada exemplo mostra um padrão vulnerável e sua alternativa segura.

SQL Injection: Código vulnerável em Kotlin

O primeiro exemplo é a concatenação direta de uma string de consulta com a entrada do usuário. Com o valor userInput = "1' OR '1'='1", a consulta retorna todas as linhas da tabela em vez de uma.

// VULNERÁVEL: concatenação de strings
fun getUserById(userInput: String): List<User> {
    val db = openOrCreateDatabase()
    val query = "SELECT * FROM users WHERE id = " + userInput
    return db.rawQuery(query, null)
}

// SEGURO: consulta parametrizada
fun getUserByIdSafe(userInput: String): List<User> {
    val db = openOrCreateDatabase()
    val query = "SELECT * FROM users WHERE id = ?"
    return db.rawQuery(query, arrayOf(userInput))
}

Proteção XSS no WebView: Swift para iOS

O segundo exemplo demonstra o carregamento incorreto e correto de conteúdo HTML do usuário no WKWebView. O uso de SwiftSoup permite remover scripts maliciosos antes da renderização.

// VULNERÁVEL: carregamento direto de HTML
let webView = WKWebView()
let html = "<div>\(userComment)</div>"
webView.loadHTMLString(html, baseURL: nil)

// SEGURO: sanitização via SwiftSoup
import SwiftSoup
let cleanHtml = try SwiftSoup.clean(
    userComment,
    Whitelist.basic()
)
webView.loadHTMLString(cleanHtml, baseURL: nil)

Command Injection: Proteção contra ataques shell em Kotlin

O terceiro exemplo é o perigo de chamar Runtime.exec() com argumentos do usuário e uma alternativa segura através de uma biblioteca com uma API fixa.

// VULNERÁVEL: comando shell com entrada do usuário
fun convertVideo(inputPath: String) {
    val cmd = "ffmpeg -i $inputPath -vcodec libx264 output.mp4"
    Runtime.getRuntime().exec(cmd)
}

// SEGURO: isolamento de argumentos
fun convertVideoSafe(inputPath: String) {
    val cmd = listOf(
        "ffmpeg", "-i", inputPath,
        "-vcodec", "libx264", "output.mp4"
    )
    ProcessBuilder(cmd).start()
}

Métodos de proteção de aplicativos móveis contra injeções

A proteção contra Code Injection requer uma abordagem sistemática que abrange código, infraestrutura e processos de desenvolvimento. Nenhum método único garante segurança completa — é necessária uma combinação de práticas.

O primeiro nível é a prevenção: validação rigorosa de todos os dados de entrada. Cada campo que o aplicativo recebe de um usuário, outro aplicativo ou da rede deve ser verificado quanto ao tipo, comprimento e formato. Bibliotecas como OWASP ESAPI fornecem validadores prontos para cenários comuns.

O segundo nível é a sanitização e escape: transformar os dados antes de usá-los em consultas SQL, templates HTML ou comandos shell. As consultas parametrizadas eliminam completamente o SQL Injection, e o escape HTML previne XSS. No Android, use Room para trabalhar com SQLite — um ORM que aplica automaticamente parâmetros bind.

O terceiro nível é a minimização de privilégios: o aplicativo deve operar com as permissões mínimas necessárias. Use o princípio do menor privilégio para o banco de dados, sistema de arquivos e comunicação entre processos. iOS implementa este princípio através do sandbox de aplicativos, e o Android através do modelo de permissões e isolamento de processos.

O quarto nível é o monitoramento e resposta: registro de operações suspeitas, detecção de anomalias e bloqueio automático na repetição de ataques. Ferramentas como Firebase App Check ajudam a detectar solicitações falsas ao backend de clientes comprometidos. A integração de RASP (Runtime Application Self-Protection) permite bloquear injeções em tempo de execução.

De acordo com um estudo do Google Project Zero (2025), a combinação desses quatro níveis reduz o risco de um ataque bem-sucedido de Code Injection em 94%. Recomenda-se que os desenvolvedores implementem mecanismos de proteção na fase de design da arquitetura, em vez de adicioná-los após a descoberta de vulnerabilidades.