RASP — vad är det, funktionsprincip och skydd i realtid

Vad är RASP?

Runtime Application Self-Protection (RASP) — en säkerhetsteknik som integreras i applikationen i byggfasen eller via en runtime-agent. RASP analyserar applikationens beteende under körning och fattar beslut om blockering av attacker baserat på kontext: var anropet kom ifrån, vilka data som överförs, vad stackens tillstånd är. Till skillnad från signaturbaserade system letar RASP inte efter kända attackmönster — det upptäcker onormalt beteende som avviker från det förväntade körningsscenariot för koden.

RASP-konceptet formaliserades av Gartner 2011, och de första kommersiella implementeringarna dök upp 2014–2015. För mobila plattformar började RASP tillämpas aktivt från 2017, när marknaden insåg att traditionell obfuskering var otillräcklig. Enligt MarketsandMarkets rapport (2025) uppgår marknadsvolymen för RASP-lösningar till 2,8 miljarder USD med en årlig tillväxt på 24,5%. Implementering av RASP rekommenderas av standarderna OWASP Mobile Top 10 och PCI DSS 4.0 för applikationer som behandlar betalningsdata.

RASP arbetar på två nivåer: interception och assessment. Interception — avlyssning av system- och biblioteksanrop via krokar som bäddas in i koden i byggfasen eller under runtime genom dynamisk instrumentering. Assessment — analys av anropskontexten: kontroll av indataparametrar, anropsstack, sandbox-status, förekomst av felsökare. Beslutet fattas baserat på den säkerhetspolicy som utvecklaren ställt in. Policyn kan vara strikt (blockera), mjuk (logga) eller adaptiv (ändra beteende beroende på hotnivå).

Hur fungerar RASP: arkitektur och mekanismer

Arkitekturen för en RASP-agent består av tre komponenter: instrumenteringsskikt, analysator och policy. Instrumenteringsskiktet fångar upp systemanrop och ramverksanrop. Analysatorn kontrollerar kontexten mot förväntade mönster. Policyn bestämmer reaktionen.

Kodinstrumentering

För mobila applikationer används kompileringstidsinstrumentering (compile-time): bytekod eller inbyggd kod modifieras i byggfasen — före varje farligt anrop infogas en kontroll. Kompilatorn för RASP-agenten modifierar ingångspunkterna FileOutputStream.write(), Runtime.exec(), Class.forName() och android.app.Activity.onStart(). För Android används DEX-bytekodtransformering via Gradle-plugin; för iOS — modifiering av Mach-O binärfil via post-link-skript.

Kontextanalys

Vid avlyssning av ett anrop analyserar RASP: den anropande klassen och metoden (vem anropar), stackspårning (anropskedja), argument (överförda data), returvärde (vad som returneras), tidsstämpel och tråd-ID. En avvikelse registreras när till exempel Runtime.exec() anropas inte från UI-tråden och inte från applikationskoden, utan från ett bibliotek som laddats via JNI med en icke-standard sökväg. Eller när FileOutputStream.write() tar emot data som innehåller körbar bytekod istället för en förväntad PNG-rubrik.

Reaktionspolicy

RASP stöder tre typer av reaktion: Block — nödstopp av applikationen vid upptäckt av attack, Log — sändning av incidentdetaljer till logginsamlingsservern utan att stoppa applikationen, Deceive — ersättning av returvärdet med ett falskt så att angriparen får felaktiga data. Kombinationen av Log och Deceive gör det möjligt att samla in underrättelser om angriparen utan att avslöja det faktum att upptäckt skett.

// Exempel: RASP-kontroll av Runtime.exec()-anrop
public class RASPAgent {
    public static Object onExecCalled(String command,
            StackTraceElement[] stack) {

        // Kontroll av anropare
        String caller = stack[1].getClassName();

        // Om anropet inte kommer från vårt paket — misstänkt
        if (!caller.startsWith("com.example.app")) {
            SecurityPolicy.reportIncident(
                "UNEXPECTED_EXEC", command, stack
            );
            return SecurityPolicy.getAction().execute(command);
        }

        // Kontrollera kommandot på svartlista
        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: tom process
            }
        }

        return null; // tillåt utförande
    }
}

RASP vs WAF och andra skyddsmedel

RASP jämförs ofta med Web Application Firewall (WAF), men den grundläggande skillnaden ligger i positioneringen. WAF finns vid nätverksperimetern och analyserar endast HTTP-begäranden. RASP fungerar inuti applikationen och ser bearbetningslogiken.

Till skillnad från obfuskering (ProGuard, DexGuard) som gör koden oläslig, upptäcker RASP aktivt attacker under exploatering. Obfuskering är passivt skydd: om angriparen lägger tillräckligt med tid på reverse engineering kommer koden att läsas. RASP är aktivt: det ser att angriparen försöker felsöka applikationen och reagerar innan en enda kodrad har lästs. Kombinationen av obfuskering + RASP ger flerskiktat skydd, där obfuskering saktar ner analysen och RASP avbryter attacken i instrumenteringsfasen.

RASP i mobila applikationer

Mobila RASP-lösningar är anpassade till Android och iOS specifika egenskaper. Till skillnad från server-Java-applikationer arbetar mobila RASP-agenter under begränsade minnes- och batteriförhållanden, vilket kräver lätt instrumentering.

RASP på Android

På Android bäddas RASP-agenten in via en Gradle-plugin som modifierar DEX-bytekoden i byggfasen. Agenten fångar upp över 50 systemanrop, inklusive: Runtime.exec() för att upptäcka start av su eller Frida, Class.forName() för att identifiera laddning av misstänkta klasser, System.loadLibrary() för att kontrollera laddning av inbyggda bibliotek från icke-standard sökvägar. Dessutom kontrolleras förekomsten i /proc/self/maps av biblioteken frida-agent, frida-helper, libinject och substrate.

RASP på iOS

På iOS implementeras RASP via efterbehandling av Mach-O binärfilen. För iOS är komplexiteten högre på grund av Apples strikta krav på modifiering av binärfiler. Agenten fångar upp anrop av funktionerna fork(), dlopen(), ptrace() och kontrollerar förekomsten av CydiaSubstrate.dylib i laddade bibliotek. RASP för iOS kan inte modifiera koden i App Store-bygget — endast för Enterprise-distribution. För App Store rekommenderas användning av kompileringstidsinstrumentering via Swift Macro eller Objective-C method swizzling.

Detektering av analysverktyg

Mobil RASP upptäcker: Frida (genom kontroll av /proc/self/maps och /data/local/tmp/frida*), Xposed Framework (genom kontroll av de.robv.android.xposed.XposedBridge i ClassLoader), JDWP-felsökare (genom Debug.isDebuggerConnected()), emulatorer (genom kontroll av Build.FINGERPRINT, Build.HARDWARE, Build.MODEL) och debuggable-flaggan i AndroidManifest. Enligt NowSecure Mobile Threat Report (2025) upptäcker RASP-agenten 89–97% av instrumenterade Frida-sessioner.

Implementering av RASP-agent i praktiken

Införande av RASP i en mobil applikation kräver konfigurering av instrumentering, definiering av policyer och integration med SIEM-system för insamling av incidentloggar.

Val av implementering: compile-time vs runtime

Kompileringstidsinstrumentering (compile-time) — modifiering av bytekod i byggfasen, som inte påverkar prestandan under runtime. Runtime-instrumentering (via Java Agent på servern eller Frida på klienten) — mer flexibel, men lägger till 5–10% overhead. För mobila applikationer rekommenderas compile-time-metoden, eftersom den inte kräver permanent nätverksanslutning och inte förbrukar batteri för analys.

Integration med befintliga bibliotek

RASP-agenten måste fungera korrekt med populära SDK:er. Firebase Crashlytics, Google Analytics och Appsee får inte blockeras. Konfigurering av vitlista för kända bibliotek är obligatorisk. I agentens konfiguration ställs undantag in: om anropet kommer från klassen com.google.firebase — hoppas kontrollen över. Vitlistan uppdateras med varje SDK-utgåva.

Exempel på incidenthantering

Vid upptäckt av Frida av RASP-agenten sker: insamling av kontext (stackspårning, OS-version, tid), sändning av data till loggningsservern i krypterad form, utförande av policy (crash, log-only eller deceive), ökning av räknare för att bestämma massattack. Data från olika enheter aggregeras på servern för att identifiera attackmönster.

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)
            }
        }
    }
}

Begränsningar och falsklarm

RASP är inte en silverkula. Tekniken har begränsningar som måste beaktas vid utformning av skydd.

Prestanda

Varje avlyssnat anrop lägger till en kontextkontroll. Vid aggressiv konfiguration (avlyssning av alla IO- och exec-anrop) kan prestandan sjunka med 5–15%. För mobila applikationer är starttiden kritisk: RASP-initiering lägger till 200–500 ms vid start. Punktinstrumentering rekommenderas — endast kritiska funktioner, inte alla möjliga funktioner. Profilering med RASP-agent är obligatorisk i testfasen.

Falsklarm

RASP kan blockera legitimt beteende: Firebase Crashlytics som skickar felstack via ett nätverksanrop kan bedömas som dataexfiltrering; Google Play Integrity API som kontrollerar enhetens integritet kan identifieras som ett misstänkt anrop. För att minska falsklarm krävs en inlärningsperiod (learning mode) på 7–14 dagar, under vilken RASP endast loggar men inte blockerar.

Kringgående av RASP

Om angriparen får åtkomst på kärnnivå (via en kärnexploit) kan RASP inte lita på ens sina egna kontroller — agenten arbetar i användarutrymmet och ser vad kärnan tillåter. För att förhindra kringgående på kärnnivå används Secure Boot Chain-kontroll i kombination med serverattestering. Dessutom måste RASP-agenten själv vara obfuskerad och skyddad mot felsökning — annars kommer angriparen att ta bort eller inaktivera RASP innan attacken påbörjas.