Code Injection in mobiele apps — wat is het, soorten aanvallen en bescherming

Wat is Code Injection?

Code Injection — een klasse van aanvallen waarbij een aanvaller uitvoerbare code in de app injecteert via onbetrouwbare invoergegevens. In mobiele apps is de aanval mogelijk via invoervelden, deep links, pushmeldingen, QR-codes en bestandsuitwisseling.

In tegenstelling tot aanvallen op OS-niveau, maakt Code Injection gebruik van logische fouten in de code van de app zelf: gebrek aan escaping, onveilige stringconcatenatie of vertrouwen op externe gegevensbronnen. Volgens het rapport van Positive Technologies (2025) vormen injecties 23% van alle kwetsbaarheden in mobiele apps in de financiële sector.

Het grootste gevaar van Code Injection — volledige compromittering van gegevens: een aanvaller kan toegang krijgen tot de database, het bestandssysteem van het apparaat of de accounts van andere gebruikers. Voor mobiele apps die met betalingsgegevens of medische informatie werken, kunnen de gevolgen kritiek zijn.

Een ontwikkelaar moet de soorten injecties begrijpen en beschermingsmechanismen op alle niveaus toepassen — van gegevensinvoer tot weergave en opslag. Moderne frameworks bieden ingebouwde beschermingsmiddelen, maar het gebruik ervan vereist een bewuste aanpak.

Belangrijkste soorten Code Injection in mobiele apps

De classificatie van Code Injection omvat drie hoofdtypen aanvallen in de context van mobiele ontwikkeling. Elk type maakt gebruik van verschillende componenten van de app en vereist specifieke beschermingsmethoden.

SQL Injection in mobiele apps

SQL Injection (SQLi) — het injecteren van kwaadaardige SQL-code via queryparameters naar een lokale of externe database. In mobiele apps ontstaat de kwetsbaarheid bij onveilig werken met SQLite op het apparaat of bij het opbouwen van HTTP-verzoeken naar REST API met stringconcatenatie.

Een typische aanvalsvector — een zoek- of filterveld waarvan de waarde direct in de SQL-query wordt ingevoegd. Als een ontwikkelaar ruwe concatenatie gebruikt in plaats van geparametriseerde queries, kan een aanvaller een string zoals 1' OR '1'='1 verzenden. Volgens OWASP Mobile Top 10 (2024) blijft SQL Injection de tweede meest voorkomende kritieke kwetsbaarheid in mobiele apps in de categorie onveilige gegevensopslag.

Bescherming tegen SQLi is gebaseerd op drie niveaus: het gebruik van geparametriseerde queries (PreparedStatement in Java, rawQuery met bindArgs in Android), validatie van invoergegevens aan client- en serverzijde en minimale databaseprivileges.

Cross-Site Scripting (XSS) in WebView

XSS-aanvallen in mobiele apps zijn gericht op de WebView-component — de ingebouwde browser die HTML-inhoud weergeeft. Als de app gegevens uit externe bronnen in WebView laadt zonder sanitizatie, kan een aanvaller JavaScript-code injecteren die wordt uitgevoerd in de context van de app.

Er worden twee subtypes van XSS onderscheiden: Stored XSS — het kwaadaardige script wordt op de server opgeslagen en uitgevoerd bij elke paginaweergave; Reflected XSS — de code wordt via URL of POST-parameters verzonden en eenmalig uitgevoerd. In mobiele apps is Stored XSS via opmerkingen, recensies of gebruikersinhoud die in WebView aan andere gebruikers wordt getoond bijzonder gevaarlijk.

Bescherming omvat het uitschakelen van JavaScript in WebView indien niet nodig, het gebruik van Content Security Policy (CSP) en sanitizatie van HTML-inhoud via bibliotheken zoals Jsoup voor Android of SwiftSoup voor iOS.

Command Injection via Intent en Shell

Command Injection — het uitvoeren van systeemopdrachten op het apparaat via onbeschermde aanroepen van Runtime.exec(), ProcessBuilder of NSTask. In mobiele apps is de aanval mogelijk als de app gebruikersgegevens doorgeeft aan shell-opdrachten of Intents met acties.

De meest kwetsbare plekken zijn bestandsconversiefuncties, het werken met media (ffmpeg, ImageMagick) en het installeren van externe bibliotheken. Een aanvaller kan een opdracht met een pijp- of omleidingsteken verzenden die willekeurige code op het apparaat uitvoert. Android beperkt shell-toegang gedeeltelijk via sandbox, maar apps met root-toegang of PrivEsc-exploits kunnen worden gecompromitteerd.

Aanbevolen bescherming — volledig afzien van Runtime.exec() voor het verwerken van gebruikersgegevens, het gebruik van bibliotheken met een veilige API en strikte isolatie van externe processen.

Hoe werkt code-injectie op Android en iOS

Het mechanisme van Code Injection verschilt op Android en iOS vanwege architectuurverschillen. Op Android zijn injecties vaak gerelateerd aan Intent — een systeembericht dat tussen app-componenten wordt verzonden. Een aanvaller kan een kwaadaardige Intent met extra gegevens met SQL-code of shell-opdrachten verzenden.

Op iOS vinden aanvallen vaker plaats via het Interprocess Communication (XPC)-mechanisme, Universal Links en de verwerking van URL Scheme. Een app die gegevens uit externe bronnen ontvangt zonder controle, wordt kwetsbaar voor injecties. Volgens Apple Security Research (2025) is ongeveer 12% van de kwetsbaarheden in iOS-apps gerelateerd aan onvoldoende sanitizatie van invoergegevens.

Een gemeenschappelijke vector voor beide platforms — aanvallen via lokale opslag (SQLite, Realm, UserDefaults). Als een kwaadaardige app gegevens naar een gedeelde map kan schrijven, kan deze code injecteren die wordt uitgevoerd door de doelapp bij het lezen.

Het proces van een typische aanval omvat drie fasen: verkenning — analyse van de invoerpunten van de app (formulieren, deep links, bestanden), injectie — het verzenden van de kwaadaardige lading via het gevonden invoerpunt en exploitatie — het uitvoeren van de injectie met toegang tot gegevens of functionaliteit. Inzicht in deze cyclus helpt de ontwikkelaar om op elke fase bescherming te ontwerpen.

Codevoorbeelden: kwetsbare en beveiligde implementaties

Laten we concrete voorbeelden van Code Injection in Kotlin voor Android en Swift voor iOS bekijken. Elk voorbeeld toont een kwetsbaar patroon en het veilige alternatief.

SQL Injection: kwetsbare code in Kotlin

Het eerste voorbeeld — directe concatenatie van de querystring met gebruikersinvoer. Bij de waarde userInput = "1' OR '1'='1" retourneert de query alle rijen van de tabel in plaats van één.

// KWETSBAAR: stringconcatenatie
fun getUserById(userInput: String): List<User> {
    val db = openOrCreateDatabase()
    val query = "SELECT * FROM users WHERE id = " + userInput
    return db.rawQuery(query, null)
}

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

XSS-bescherming in WebView: Swift voor iOS

Het tweede voorbeeld toont het onjuist en correct laden van gebruikers-HTML-inhoud in WKWebView. Het gebruik van SwiftSoup maakt het mogelijk om kwaadaardige scripts te verwijderen voordat ze worden weergegeven.

// KWETSBAAR: direct HTML laden
let webView = WKWebView()
let html = "<div>\(userComment)</div>"
webView.loadHTMLString(html, baseURL: nil)

// VEILIG: sanitizatie via SwiftSoup
import SwiftSoup
let cleanHtml = try SwiftSoup.clean(
    userComment,
    Whitelist.basic()
)
webView.loadHTMLString(cleanHtml, baseURL: nil)

Command Injection: bescherming tegen shell-aanvallen in Kotlin

Het derde voorbeeld — het gevaar van het aanroepen van Runtime.exec() met gebruikersargumenten en het veilige alternatief via een bibliotheek met een vaste API.

// KWETSBAAR: shell-commando met gebruikersinvoer
fun convertVideo(inputPath: String) {
    val cmd = "ffmpeg -i $inputPath -vcodec libx264 output.mp4"
    Runtime.getRuntime().exec(cmd)
}

// VEILIG: isolatie van argumenten
fun convertVideoSafe(inputPath: String) {
    val cmd = listOf(
        "ffmpeg", "-i", inputPath,
        "-vcodec", "libx264", "output.mp4"
    )
    ProcessBuilder(cmd).start()
}

Methoden om mobiele apps te beschermen tegen injecties

Bescherming tegen Code Injection vereist een systematische aanpak die code, infrastructuur en ontwikkelprocessen omvat. Geen enkele individuele methode garandeert volledige beveiliging — een combinatie van praktijken is noodzakelijk.

Eerste niveau — preventie: strikte validatie van alle invoergegevens. Elk veld dat de app ontvangt van de gebruiker, een andere app of het netwerk moet worden gecontroleerd op type, lengte en formaat. Bibliotheken zoals OWASP ESAPI bieden kant-en-klare validators voor gangbare scenario's.

Tweede niveau — sanitizatie en escaping: het transformeren van gegevens voordat ze worden gebruikt in SQL-queries, HTML-sjablonen of shell-opdrachten. Geparametriseerde queries elimineren SQL Injection volledig en HTML-escaping voorkomt XSS. Gebruik op Android voor het werken met SQLite Room — een ORM die automatisch bind-parameters toepast.

Derde niveau — minimalisatie van privileges: de app moet werken met de minimaal noodzakelijke rechten. Pas het principe van最小 privilege toe voor de database, het bestandssysteem en interprocescommunicatie. iOS implementeert dit principe via de app-sandbox en Android via het machtigingenmodel en procesisolatie.

Vierde niveau — monitoring en respons: het loggen van verdachte operaties, detectie van afwijkingen en automatische blokkering bij herhaalde aanvallen. Tools zoals Firebase App Check helpen bij het detecteren van valse verzoeken aan de backend van gecompromitteerde clients. Integratie van RASP (Runtime Application Self-Protection) maakt het mogelijk om injecties tijdens runtime te blokkeren.

Volgens onderzoek van Google Project Zero (2025) vermindert de combinatie van deze vier niveaus het risico op een succesvolle aanval via Code Injection met 94%. Ontwikkelaars wordt aangeraden om beschermingsmechanismen in de ontwerpfase van de architectuur te implementeren, niet na het ontdekken van een kwetsbaarheid.