Code Injection i mobilappar — vad det är, typer av attacker och skydd

Vad är Code Injection?

Code Injection — en klass av attacker där angriparen injicerar exekverbar kod i appen via otillförlitlig indata. I mobilappar är attacken möjlig via inmatningsfält, deep links, push-notiser, QR-koder och filutbyte.

Till skillnad från attacker på operativsystemsnivå utnyttjar Code Injection logiska fel i själva appkoden: brist på escaping, osäker strängkonkatenering eller förtroende för externa datakällor. Enligt rapporten från Positive Technologies (2025) utgör injiceringar 23% av alla sårbarheter i mobilappar inom finanssektorn.

Den största faran med Code Injection — fullständig kompromettering av data: angriparen kan få tillgång till databasen, enhetens filsystem eller andra användares konton. För mobilappar som arbetar med betalningsdata eller medicinsk information kan konsekvenserna vara kritiska.

Utvecklaren måste förstå typerna av injiceringar och tillämpa skyddsmekanismer på alla nivåer — från datainmatning till visning och lagring. Moderna ramverk tillhandahåller inbyggda skyddsverktyg, men deras användning kräver ett medvetet förhållningssätt.

Huvudtyper av Code Injection i mobilappar

Klassificeringen av Code Injection omfattar tre huvudtyper av attacker inom mobilutveckling. Varje typ utnyttjar olika komponenter i appen och kräver specifika skyddsmetoder.

SQL Injection i mobilappar

SQL Injection (SQLi) — injicering av skadlig SQL-kod via frågeparametrar till en lokal eller fjärrdatabas. I mobilappar uppstår sårbarheten vid osäker hantering av SQLite på enheten eller vid konstruktion av HTTP-förfrågningar till REST API med strängkonkatenering.

En typisk attackvektor — ett sök- eller filterfält vars värde direkt infogas i SQL-frågan. Om utvecklaren använder rå konkatenering istället för parameteriserade frågor kan angriparen skicka en sträng som 1' OR '1'='1. Enligt OWASP Mobile Top 10 (2024) är SQL Injection fortfarande den näst vanligaste kritiska sårbarheten i mobilappar inom kategorin osäker datalagring.

Skydd mot SQLi baseras på tre nivåer: användning av parameteriserade frågor (PreparedStatement i Java, rawQuery med bindArgs i Android), validering av indata på klient- och serversidan samt minimala databasprivilegier.

Cross-Site Scripting (XSS) i WebView

XSS-attacker i mobilappar riktar sig mot WebView-komponenten — den inbyggda webbläsaren som visar HTML-innehåll. Om appen laddar data från externa källor i WebView utan sanitisering kan angriparen injicera JavaScript-kod som exekveras i appens kontext.

Två undertyper av XSS särskiljs: Stored XSS — det skadliga skriptet lagras på servern och exekveras vid varje sidvisning; Reflected XSS — koden skickas via URL eller POST-parametrar och exekveras en gång. I mobilappar är Stored XSS via kommentarer, recensioner eller användarinnehåll som visas i WebView för andra användare särskilt farligt.

Skydd inkluderar att inaktivera JavaScript i WebView om det inte behövs, använda Content Security Policy (CSP) och sanitisera HTML-innehåll via bibliotek som Jsoup för Android eller SwiftSoup för iOS.

Command Injection via Intent och Shell

Command Injection — exekvering av systemkommandon på enheten via oskyddade anrop till Runtime.exec(), ProcessBuilder eller NSTask. I mobilappar är attacken möjlig om appen skickar användardata till shell-kommandon eller Intents med åtgärder.

De mest sårbara platserna är filkonverteringsfunktioner, arbete med media (ffmpeg, ImageMagick) och installation av externa bibliotek. Angriparen kan skicka ett kommando med en pip- eller omdirigeringssymbol som exekverar godtycklig kod på enheten. Android begränsar delvis shell-åtkomst via sandbox, men appar med root-åtkomst eller PrivEsc-exploater kan komprometteras.

Rekommenderat skydd — att helt avstå från Runtime.exec() för bearbetning av användardata, använda bibliotek med säkert API och strikt isolering av externa processer.

Hur kod injicering fungerar på Android och iOS

Mekanismen för Code Injection skiljer sig på plattformarna Android och iOS på grund av arkitektoniska skillnader. På Android är injiceringar ofta kopplade till Intent — systemmeddelandet som skickas mellan appkomponenter. Angriparen kan skicka en skadlig Intent med extra data som innehåller SQL-kod eller shell-kommandon.

På iOS sker attacker oftare via mekanismen Interprocess Communication (XPC), Universal Links och bearbetning av URL Scheme. En app som tar emot data från externa källor utan kontroll blir sårbar för injiceringar. Enligt Apple Security Research (2025) är cirka 12% av sårbarheterna i iOS-appar kopplade till otillräcklig sanitisering av indata.

En gemensam vektor för båda plattformarna — attack via lokal lagring (SQLite, Realm, UserDefaults). Om en skadlig app kan skriva data till en delad katalog kan den injicera kod som exekveras av målappen vid läsning.

Processen för en typisk attack omfattar tre steg: rekognosering — analys av appens ingångspunkter (formulär, deep links, filer), injicering — sändning av den skadliga lasten via den funna ingångspunkten och exploatering — exekvering av injiceringen med åtkomst till data eller funktionalitet. Att förstå denna cykel hjälper utvecklaren att designa skydd i varje steg.

Kodexempel: sårbara och säkra implementationer

Låt oss titta på konkreta exempel på Code Injection i Kotlin för Android och Swift för iOS. Varje exempel visar ett sårbart mönster och dess säkra alternativ.

SQL Injection: sårbar kod i Kotlin

Det första exemplet — direkt konkatenering av frågesträngen med användarinmatning. Vid värdet userInput = "1' OR '1'='1" returnerar frågan alla rader i tabellen istället för en.

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

// SÄKERT: parameteriserad fråga
fun getUserByIdSafe(userInput: String): List<User> {
    val db = openOrCreateDatabase()
    val query = "SELECT * FROM users WHERE id = ?"
    return db.rawQuery(query, arrayOf(userInput))
}

XSS-skydd i WebView: Swift för iOS

Det andra exemplet visar felaktig och korrekt laddning av användarens HTML-innehåll i WKWebView. Användning av SwiftSoup gör det möjligt att ta bort skadliga skript före visning.

// SÅRBART: direkt HTML-laddning
let webView = WKWebView()
let html = "<div>\(userComment)</div>"
webView.loadHTMLString(html, baseURL: nil)

// SÄKERT: sanitisering via SwiftSoup
import SwiftSoup
let cleanHtml = try SwiftSoup.clean(
    userComment,
    Whitelist.basic()
)
webView.loadHTMLString(cleanHtml, baseURL: nil)

Command Injection: skydd mot shell-attacker i Kotlin

Det tredje exemplet — faran med att anropa Runtime.exec() med användarargument och det säkra alternativet via ett bibliotek med fast API.

// SÅRBART: shell-kommando med användarinmatning
fun convertVideo(inputPath: String) {
    val cmd = "ffmpeg -i $inputPath -vcodec libx264 output.mp4"
    Runtime.getRuntime().exec(cmd)
}

// SÄKERT: isolering av argument
fun convertVideoSafe(inputPath: String) {
    val cmd = listOf(
        "ffmpeg", "-i", inputPath,
        "-vcodec", "libx264", "output.mp4"
    )
    ProcessBuilder(cmd).start()
}

Metoder för att skydda mobilappar från injiceringar

Skydd mot Code Injection kräver ett systematiskt tillvägagångssätt som omfattar kod, infrastruktur och utvecklingsprocesser. Ingen enskild metod garanterar fullständig säkerhet — en kombination av metoder är nödvändig.

Första nivån — förebyggande: strikt validering av all indata. Varje fält som appen tar emot från användaren, en annan app eller nätverket måste kontrolleras för typ, längd och format. Bibliotek som OWASP ESAPI tillhandahåller färdiga validerare för vanliga scenarier.

Andra nivån — sanitisering och escaping: transformering av data innan de används i SQL-frågor, HTML-mallar eller shell-kommandon. Parameteriserade frågor eliminerar helt SQL Injection och HTML-escaping förhindrar XSS. På Android, för arbete med SQLite, använd Room — ett ORM som automatiskt tillämpar bind-parametrar.

Tredje nivån — minimering av privilegier: appen bör fungera med minimalt nödvändiga rättigheter. Tillämpa principen om minsta privilegium för databasen, filsystemet och interprocesskommunikation. iOS implementerar denna princip via app-sandbox och Android via behörighetsmodellen och processisolering.

Fjärde nivån — övervakning och respons: loggning av misstänkta operationer, detektering av avvikelser och automatisk blockering vid upprepade attacker. Verktyg som Firebase App Check hjälper till att upptäcka falska förfrågningar till backend från komprometterade klienter. Integration av RASP (Runtime Application Self-Protection) gör det möjligt att blockera injiceringar under körning.

Enligt forskning från Google Project Zero (2025) minskar kombinationen av dessa fyra nivåer risken för en framgångsrik attack via Code Injection med 94%. Utvecklare rekommenderas att implementera skyddsmekanismer i arkitekturdesignfasen, inte efter att en sårbarhet upptäckts.