RASP — o que é, princípio de funcionamento e proteção em tempo real

O que é RASP?

Runtime Application Self-Protection (RASP) é uma tecnologia de segurança integrada na aplicação durante a compilação ou através de um agente em tempo de execução. O RASP analisa o comportamento da aplicação durante a execução e toma decisões para bloquear ataques com base no contexto: de onde veio a chamada, quais dados estão a ser transmitidos, qual é o estado da pilha. Ao contrário dos sistemas baseados em assinaturas, o RASP não procura padrões de ataque conhecidos — ele deteta comportamentos anómalos que se desviam do cenário de execução esperado.

O conceito de RASP foi formalizado pela Gartner em 2011, e as primeiras implementações comerciais surgiram em 2014–2015. Para plataformas móveis, o RASP começou a ser ativamente utilizado em 2017, quando o mercado percebeu a insuficiência da ofuscação tradicional. De acordo com o relatório da MarketsandMarkets (2025), o mercado de soluções RASP é de 2,8 mil milhões de USD com um crescimento anual de 24,5%. A implementação de RASP é recomendada pelos padrões OWASP Mobile Top 10 e PCI DSS 4.0 para aplicações que processam dados de pagamento.

O RASP opera em dois níveis: interceção e avaliação. A interceção é a captura de chamadas de sistema e de bibliotecas através de hooks incorporados no código durante a compilação ou em tempo de execução através de instrumentação dinâmica. A avaliação é a análise do contexto da chamada: verificação de parâmetros de entrada, pilha de chamadas, estado da sandbox, presença do depurador. A decisão é tomada com base na política de segurança definida pelo programador. A política pode ser rigorosa (bloquear), suave (registar) ou adaptativa (alterar o comportamento conforme o nível de ameaça).

Como funciona o RASP: arquitetura e mecanismos

A arquitetura do agente RASP consiste em três componentes: camada de instrumentação, analisador e política. A camada de instrumentação interceta chamadas de sistema e do framework. O analisador verifica o contexto contra padrões esperados. A política determina a resposta.

Instrumentação de código

Para aplicações móveis, utiliza-se instrumentação em tempo de compilação: o bytecode ou código nativo é modificado durante a compilação — uma verificação é inserida antes de cada chamada perigosa. O compilador do agente RASP modifica os pontos de entrada FileOutputStream.write(), Runtime.exec(), Class.forName() e android.app.Activity.onStart(). Para Android, utiliza-se transformação de bytecode DEX através do Gradle plugin; para iOS, modificação do binário Mach-O através de script post-link.

Análise de contexto

Ao intercetar uma chamada, o RASP analisa: classe e método caller (quem está a chamar), stack trace (cadeia de chamadas), argumentos (dados transmitidos), valor de retorno (o que é retornado), timestamp e id da thread. Uma anomalia é registada quando, por exemplo, Runtime.exec() é chamado não a partir da thread de UI nem do código da aplicação, mas a partir de uma biblioteca carregada via JNI com um caminho não padrão. Ou quando FileOutputStream.write() recebe dados contendo bytecode executável em vez do cabeçalho PNG esperado.

Políticas de resposta

O RASP suporta três tipos de resposta: Block — encerramento forçado da aplicação ao detetar um ataque, Log — envio de detalhes do incidente para o servidor de registo sem parar a aplicação, Deceive — substituição do valor de retorno por um falso para que o atacante receba dados incorretos. A combinação de Log e Deceive permite recolher informações sobre o atacante sem revelar o facto da deteção.

// Exemplo: verificação RASP da chamada Runtime.exec()
public class RASPAgent {
    public static Object onExecCalled(String command,
            StackTraceElement[] stack) {

        // Verificando caller
        String caller = stack[1].getClassName();

        // Se a chamada não for do nosso pacote — suspeito
        if (!caller.startsWith("com.example.app")) {
            SecurityPolicy.reportIncident(
                "UNEXPECTED_EXEC", command, stack
            );
            return SecurityPolicy.getAction().execute(command);
        }

        // Verificando comando contra lista negra
        String[] blocked = {"su", "frida", "ptrace", "/data/local"};
        for (String pattern : blocked) {
            if (command.contains(pattern)) {
                SecurityPolicy.reportIncident(
                    "BLOCKED_CMD", command, stack
                );
                return new Process(); // deceiving: processo vazio
            }
        }

        return null; // permitir execução
    }
}

RASP vs WAF e outras ferramentas de segurança

O RASP é frequentemente comparado com o Web Application Firewall (WAF), mas a diferença fundamental está no posicionamento. O WAF está localizado na periferia da rede e analisa apenas solicitações HTTP. O RASP opera dentro da aplicação e vê a lógica de processamento.

Ao contrário da ofuscação (ProGuard, DexGuard), que torna o código ilegível, o RASP deteta ativamente ataques durante a exploração. A ofuscação é proteção passiva: se o atacante dedicar tempo suficiente à engenharia reversa, o código será lido. O RASP é ativo: vê que o atacante está a tentar depurar a aplicação e responde antes que uma única linha de código seja lida. A combinação de ofuscação + RASP fornece proteção em várias camadas, onde a ofuscação retarda a análise e o RASP interrompe o ataque na fase de instrumentação.

RASP em aplicações móveis

As soluções RASP móveis estão adaptadas às especificidades do Android e iOS. Ao contrário das aplicações Java de servidor, os agentes RASP móveis operam com memória e bateria limitadas, exigindo instrumentação leve.

RASP no Android

No Android, o agente RASP é incorporado através de um plugin Gradle que modifica o bytecode DEX durante a compilação. O agente interceta mais de 50 chamadas de sistema, incluindo: Runtime.exec() para detetar execução de su ou Frida, Class.forName() para identificar carregamento de classes suspeitas, System.loadLibrary() para controlar o carregamento de bibliotecas nativas de caminhos não padrão. Adicionalmente, verifica em /proc/self/maps as bibliotecas frida-agent, frida-helper, libinject e substrate.

RASP no iOS

No iOS, o RASP é implementado através do pós-processamento do binário Mach-O. O iOS é mais complexo devido aos requisitos rigorosos da Apple para modificação de binários. O agente interceta chamadas às funções fork(), dlopen(), ptrace() e verifica a presença de CydiaSubstrate.dylib entre as bibliotecas carregadas. O RASP para iOS não pode modificar código em builds da App Store — apenas para distribuição Enterprise. Para a App Store, recomenda-se instrumentação em tempo de compilação através de Swift Macro ou method swizzling de Objective-C.

Deteção de ferramentas de análise

O RASP móvel deteta: Frida (através de verificação de /proc/self/maps e /data/local/tmp/frida*), Xposed Framework (através de verificação de de.robv.android.xposed.XposedBridge no ClassLoader), depurador JDWP (através de Debug.isDebuggerConnected()), emuladores (através de verificação de Build.FINGERPRINT, Build.HARDWARE, Build.MODEL) e a flag debuggable no AndroidManifest. De acordo com o NowSecure Mobile Threat Report (2025), um agente RASP deteta 89–97% das sessões instrumentadas de Frida.

Implementação prática de um agente RASP

A integração do RASP numa aplicação móvel requer configurar a instrumentação, definir políticas e integrar com um sistema SIEM para recolha de registos de incidentes.

Escolha de implementação: compile-time vs runtime

A instrumentação em tempo de compilação — modificação do bytecode durante a compilação, não afeta o desempenho em tempo de execução. A instrumentação em tempo de execução (através de Java Agent no servidor ou Frida no cliente) é mais flexível, mas adiciona 5–10% de sobrecarga. Para aplicações móveis, recomenda-se a abordagem de tempo de compilação, pois não requer conexão constante à rede nem consome bateria para análise.

Integração com bibliotecas existentes

O agente RASP deve funcionar corretamente com SDKs populares. Firebase Crashlytics, Google Analytics e Appsee não devem ser bloqueados. A configuração de whitelist para bibliotecas conhecidas é obrigatória. Na configuração do agente, especificam-se exceções: se uma chamada vier da classe com.google.firebase — a verificação é ignorada. A whitelist é atualizada com cada versão do SDK.

Exemplo de tratamento de incidentes

Quando o Frida é detetado através do agente RASP, ocorre o seguinte: recolha de contexto (stack trace, versão do SO, hora), envio de dados para o servidor de registo de forma cifrada, execução da política (crash, apenas registo ou deceive), incremento de um contador para identificar um ataque em massa. Os dados de diferentes dispositivos são agregados no servidor para identificar padrões de ataque.

class RASPManager {
    fun analyzeAndReact() {
        val threats = detectThreats()
        if (threats.isNotEmpty()) {
            val report = ThreatReport().apply {
                threats = threats
                timestamp = System.currentTimeMillis()
                deviceId = DeviceInfo.getHashedId()
                stackTrace = Thread
                    .currentThread()
                    .stackTrace
                    .take(10)
                    .toList()
            }

            val policy = SecurityPolicy.getPolicy(threats.maxBy { it.severity })

            when (policy) {
                Policy.BLOCK   -> throw SecurityException("Protection triggered")
                Policy.LOG     -> ServerLogger.sendReport(report)
                Policy.DECEIVE -> DeceptionLayer.activate(report)
            }
        }
    }
}

Limitações e falsos positivos

O RASP não é uma bala de prata. A tecnologia tem limitações que devem ser consideradas ao projetar a proteção.

Desempenho

Cada chamada intercetada adiciona uma verificação de contexto. Com uma configuração agressiva (intercetar todas as chamadas de IO e exec), o desempenho pode cair 5–15%. O tempo de inicialização é crítico para aplicações móveis: a inicialização do RASP adiciona 200–500 ms no arranque. Recomenda-se instrumentação seletiva — apenas funções críticas, não todas as possíveis. A criação de perfis com o agente RASP é obrigatória durante os testes.

Falsos positivos

O RASP pode bloquear comportamento legítimo: o Firebase Crashlytics a enviar uma pilha de erros através de uma chamada de rede pode ser confundido com exfiltração de dados; a API Google Play Integrity a verificar a integridade do dispositivo pode ser identificada como uma chamada suspeita. Para reduzir falsos positivos, é necessário um período de modo de aprendizagem (learning mode) de 7–14 dias, durante o qual o RASP apenas regista mas não bloqueia.

Contorno do RASP

Se um atacante obtiver acesso ao nível do kernel (através de um exploit do kernel), o RASP não pode confiar nem nas suas próprias verificações — o agente opera no espaço do utilizador e vê apenas o que o kernel lhe permite ver. Para prevenir o contorno ao nível do kernel, utiliza-se a verificação de Secure Boot Chain em combinação com atestação do servidor. Além disso, o próprio agente RASP deve estar ofuscado e protegido contra depuração — caso contrário, o atacante removerá ou desativará o RASP antes de lançar o ataque.