Code Injection mobilos alkalmazásokban — mi ez, támadástípusok és védelem

Mi az a Code Injection?

Code Injection — olyan támadások osztálya, amelyek során a támadó végrehajtható kódot juttat az alkalmazásba megbízhatatlan bemeneti adatokon keresztül. Mobilalkalmazásokban a támadás beviteli mezőkön, deep link-eken, push értesítéseken, QR-kódokon és fájlcserén keresztül lehetséges.

Az operációs rendszer szintű támadásokkal ellentétben a Code Injection az alkalmazás saját kódjában lévő logikai hibákat használja ki: az escaping hiányát, a nem biztonságos stringkonkatenációt vagy a külső adatforrásokba vetett bizalmat. A Positive Technologies (2025) jelentése szerint az injektálások a pénzügyi szektor mobilalkalmazásaiban az összes sebezhetőség 23%-át teszik ki.

A Code Injection fő veszélye — az adatok teljes kompromittálása: a támadó hozzáférhet az adatbázishoz, a készülék fájlrendszeréhez vagy más felhasználók fiókjaihoz. A fizetési adatokkal vagy orvosi információkkal dolgozó mobilalkalmazások esetében a következmények kritikusak lehetnek.

A fejlesztőnek meg kell értenie az injektálások típusait, és minden szinten — az adatbeviteltől a megjelenítésig és tárolásig — védelmi mechanizmusokat kell alkalmaznia. A modern keretrendszerek beépített védelmi eszközöket biztosítanak, de használatuk tudatos megközelítést igényel.

A Code Injection fő típusai mobilalkalmazásokban

A Code Injection osztályozása három fő támadástípust foglal magában a mobilfejlesztés kontextusában. Minden típus az alkalmazás különböző összetevőit használja ki, és specifikus védelmi módszereket igényel.

SQL Injection mobilalkalmazásokban

SQL Injection (SQLi) — rosszindulatú SQL-kód bejuttatása a lekérdezésparamétereken keresztül a helyi vagy távoli adatbázisba. Mobilalkalmazásokban a sebezhetőség az eszközön lévő SQLite-tal való nem biztonságos munkavégzés során, vagy a REST API-hoz történő HTTP-kérések stringkonkatenációval történő felépítésekor keletkezik.

A tipikus támadási vektor — egy kereső vagy szűrőmező, amelynek értéke közvetlenül beillesztésre kerül az SQL-lekérdezésbe. Ha a fejlesztő paraméterezett lekérdezések helyett nyers konkatenációt használ, a támadó olyan karakterláncot küldhet, mint a 1' OR '1'='1. A OWASP Mobile Top 10 (2024) szerint az SQL Injection továbbra is a második leggyakoribb kritikus sebezhetőség a mobilalkalmazásokban a nem biztonságos adattárolás kategóriájában.

Az SQLi elleni védelem három szinten alapul: paraméterezett lekérdezések használata (PreparedStatement Java-ban, rawQuery bindArgs-szal Androidban), a bemeneti adatok validálása az ügyfél- és szerveroldalon, valamint az adatbázis minimális jogosultságai.

Cross-Site Scripting (XSS) WebView-ban

Az XSS-támadások a mobilalkalmazásokban a WebView összetevőt — a HTML-tartalmat megjelenítő beépített böngészőt — célozzák. Ha az alkalmazás szanitizálás nélkül tölt be adatokat külső forrásokból a WebView-ba, a támadó JavaScript-kódot injektálhat, amely az alkalmazás kontextusában hajtódik végre.

Az XSS-nek két altípusa különböztethető meg: Stored XSS — a rosszindulatú szkript a szerveren tárolódik, és minden oldalmegtekintéskor végrehajtódik; Reflected XSS — a kód URL-en vagy POST-paramétereken keresztül kerül továbbításra, és egyszer hajtódik végre. Mobilalkalmazásokban a Stored XSS a WebView-ban más felhasználók számára megjelenített megjegyzéseken, értékeléseken vagy felhasználói tartalmakon keresztül különösen veszélyes.

A védelem magában foglalja a JavaScript letiltását a WebView-ban, ha nem szükséges, a Content Security Policy (CSP) használatát, valamint a HTML-tartalom szanitizálását olyan könyvtárak segítségével, mint a Jsoup Androidhoz vagy a SwiftSoup iOS-hez.

Command Injection Intent-en és Shell-en keresztül

Command Injection — rendszerparancsok végrehajtása az eszközön Runtime.exec(), ProcessBuilder vagy NSTask védtelen hívásain keresztül. Mobilalkalmazásokban a támadás akkor lehetséges, ha az alkalmazás felhasználói adatokat továbbít shell-parancsokhoz vagy Intent-ekhez műveletekkel.

A legsérülékenyebb helyek a fájlkonverziós funkciók, a médiával való munka (ffmpeg, ImageMagick) és a külső könyvtárak telepítése. A támadó olyan parancsot küldhet, amely csővezeték- vagy átirányítási jelet tartalmaz, és tetszőleges kódot hajt végre az eszközön. Az Android részben korlátozza a shell-hozzáférést a homokozón (sandbox) keresztül, de a root hozzáféréssel vagy PrivEsc exploitokkal rendelkező alkalmazások kompromittálódhatnak.

Ajánlott védelem — a Runtime.exec() teljes elhagyása a felhasználói adatok feldolgozásához, biztonságos API-val rendelkező könyvtárak használata és a külső folyamatok szigorú elkülönítése.

Hogyan működik a kód injektálás Androidon és iOS-en

A Code Injection mechanizmusa az Android és iOS platformokon az architekturális különbségek miatt eltérő. Androidon az injektálások gyakran kapcsolódnak az Intent-hez — az alkalmazás összetevői között továbbított rendszerüzenethez. A támadó rosszindulatú Intent-et küldhet extra adatokkal, amelyek SQL-kódot vagy shell-parancsokat tartalmaznak.

iOS-en a támadások gyakrabban fordulnak elő az Interprocess Communication (XPC), az Universal Links és az URL Scheme feldolgozás mechanizmusán keresztül. Az az alkalmazás, amely külső forrásokból érkező adatokat ellenőrzés nélkül fogad, sebezhetővé válik az injektálásokkal szemben. Az Apple Security Research (2025) szerint az iOS-alkalmazások sebezhetőségeinek körülbelül 12%-a a bemeneti adatok elégtelen szanitizálásához kapcsolódik.

Mindkét platform közös vektora — a helyi tárolón (SQLite, Realm, UserDefaults) keresztüli támadás. Ha egy rosszindulatú alkalmazás képes adatokat írni egy megosztott könyvtárba, akkor olyan kódot injektálhat, amelyet a célalkalmazás az olvasás során végrehajt.

Egy tipikus támadás folyamata három szakaszból áll: felderítés — az alkalmazás belépési pontjainak (űrlapok, deep link-ek, fájlok) elemzése, injektálás — a rosszindulatú teher elküldése a megtalált belépési ponton keresztül, és kihasználás — az injektálás végrehajtása az adatokhoz vagy funkciókhoz való hozzáférés megszerzésével. Ennek a ciklusnak a megértése segít a fejlesztőnek minden szakaszban védelmet tervezni.

Kódpéldák: sebezhető és biztonságos implementációk

Nézzünk konkrét példákat a Code Injection-re Kotlinban Androidhoz és Swift-ben iOS-hez. Minden példa egy sebezhető mintát és annak biztonságos alternatíváját mutatja be.

SQL Injection: sebezhető kód Kotlinban

Az első példa — a lekérdezési karakterlánc közvetlen összefűzése a felhasználói bemenettel. A userInput = "1' OR '1'='1" értéknél a lekérdezés a tábla összes sorát visszaadja egy helyett.

// SÉRÜLÉKENY: stringkonkatenáció
fun getUserById(userInput: String): List<User> {
    val db = openOrCreateDatabase()
    val query = "SELECT * FROM users WHERE id = " + userInput
    return db.rawQuery(query, null)
}

// BIZTONSÁGOS: paraméterezett lekérdezés
fun getUserByIdSafe(userInput: String): List<User> {
    val db = openOrCreateDatabase()
    val query = "SELECT * FROM users WHERE id = ?"
    return db.rawQuery(query, arrayOf(userInput))
}

XSS védelem WebView-ban: Swift iOS-hez

A második példa a felhasználói HTML-tartalom helytelen és helyes betöltését mutatja be a WKWebView-ban. A SwiftSoup használata lehetővé teszi a rosszindulatú szkriptek eltávolítását a megjelenítés előtt.

// SÉRÜLÉKENY: közvetlen HTML betöltés
let webView = WKWebView()
let html = "<div>\(userComment)</div>"
webView.loadHTMLString(html, baseURL: nil)

// BIZTONSÁGOS: sanitizáció SwiftSoup segítségével
import SwiftSoup
let cleanHtml = try SwiftSoup.clean(
    userComment,
    Whitelist.basic()
)
webView.loadHTMLString(cleanHtml, baseURL: nil)

Command Injection: védelem shell-támadások ellen Kotlinban

A harmadik példa — a Runtime.exec() felhasználói argumentumokkal történő meghívásának veszélye és a biztonságos alternatíva fix API-val rendelkező könyvtáron keresztül.

// SÉRÜLÉKENY: shell parancs felhasználói bemenettel
fun convertVideo(inputPath: String) {
    val cmd = "ffmpeg -i $inputPath -vcodec libx264 output.mp4"
    Runtime.getRuntime().exec(cmd)
}

// BIZTONSÁGOS: argumentumok elkülönítése
fun convertVideoSafe(inputPath: String) {
    val cmd = listOf(
        "ffmpeg", "-i", inputPath,
        "-vcodec", "libx264", "output.mp4"
    )
    ProcessBuilder(cmd).start()
}

A mobilalkalmazások védelmének módszerei az injektálások ellen

A Code Injection elleni védelem szisztematikus megközelítést igényel, amely lefedi a kódot, az infrastruktúrát és a fejlesztési folyamatokat. Egyetlen módszer sem garantálja a teljes biztonságot — a gyakorlatok kombinációja szükséges.

Első szint — megelőzés: az összes bemeneti adat szigorú validálása. Minden mezőt, amelyet az alkalmazás a felhasználótól, egy másik alkalmazástól vagy a hálózattól kap, ellenőrizni kell típus, hossz és formátum szerint. Az olyan könyvtárak, mint az OWASP ESAPI, kész érvényesítőket biztosítanak a gyakori forgatókönyvekhez.

Második szint — szanitizálás és escaping: az adatok átalakítása az SQL-lekérdezésekben, HTML-sablonokban vagy shell-parancsokban való felhasználás előtt. A paraméterezett lekérdezések teljesen kiküszöbölik az SQL Injection-t, a HTML escaping pedig megakadályozza az XSS-t. Androidon az SQLite-tal való munkához használja a Room-ot — egy ORM-et, amely automatikusan alkalmazza a bind paramétereket.

Harmadik szint — a jogosultságok minimalizálása: az alkalmazásnak a minimálisan szükséges jogokkal kell működnie. Alkalmazza a legkevesebb jogosultság elvét az adatbázisra, a fájlrendszerre és a folyamatközi kommunikációra. Az iOS ezt az elvet az alkalmazások homokozóján keresztül, az Android pedig az engedélymodellen és a folyamatok elkülönítésén keresztül valósítja meg.

Negyedik szint — monitorozás és reagálás: a gyanús műveletek naplózása, anomáliák észlelése és automatikus blokkolás ismétlődő támadások esetén. Az olyan eszközök, mint a Firebase App Check, segítenek észlelni a hamis kéréseket a backendhez a kompromittált kliensektől. Az RASP (Runtime Application Self-Protection) integrációja lehetővé teszi az injektálások blokkolását futás közben.

A Google Project Zero (2025) kutatása szerint e négy szint kombinációja 94%-kal csökkenti a sikeres Code Injection támadás kockázatát. A fejlesztőknek ajánlott a védelmi mechanizmusokat az architektúra tervezési szakaszában bevezetni, nem pedig a sebezhetőség felfedezése után.