Code Injection v mobilních aplikacích — co to je, typy útoků a ochrana

Co je Code Injection?

Code Injection — třída útoků, při kterých útočník vkládá spustitelný kód do aplikace prostřednictvím nedůvěryhodných vstupních dat. V mobilních aplikacích je útok možný přes vstupní pole, deep linky, push notifikace, QR kódy a výměnu souborů.

Na rozdíl od útoků na úrovni operačního systému využívá Code Injection logické chyby v kódu samotné aplikace: chybějící escapování, nebezpečnou konkatenaci řetězců nebo důvěru v externí zdroje dat. Podle zprávy Positive Technologies (2025) tvoří injekce 23 % všech zranitelností v mobilních aplikacích finančního sektoru.

Hlavní nebezpečí Code Injection — úplné kompromitování dat: útočník může získat přístup k databázi, souborovému systému zařízení nebo účtům ostatních uživatelů. Pro mobilní aplikace pracující s platebními údaji nebo lékařskými informacemi mohou být následky kritické.

Vývojář musí rozumět typům injekcí a aplikovat ochranné mechanismy na všech úrovních — od vstupu dat po jejich zobrazení a ukládání. Moderní frameworky poskytují vestavěné ochranné prostředky, ale jejich použití vyžaduje vědomý přístup.

Hlavní typy Code Injection v mobilních aplikacích

Klasifikace Code Injection zahrnuje tři hlavní typy útoků v kontextu mobilního vývoje. Každý typ využívá různé komponenty aplikace a vyžaduje specifické metody ochrany.

SQL Injection v mobilních aplikacích

SQL Injection (SQLi) — vložení škodlivého SQL kódu prostřednictvím parametrů dotazů do lokální nebo vzdálené databáze. V mobilních aplikacích vzniká zranitelnost při nebezpečné práci s SQLite na zařízení nebo při vytváření HTTP požadavků na REST API s konkatenací řetězců.

Typický vektor útoku — vyhledávací nebo filtrační pole, jehož hodnota je přímo vložena do SQL dotazu. Pokud vývojář používá surovou konkatenaci místo parametrizovaných dotazů, může útočník odeslat řetězec jako 1' OR '1'='1. Podle OWASP Mobile Top 10 (2024) zůstává SQL Injection druhou nejčastější kritickou zranitelností v mobilních aplikacích v kategorii nebezpečného ukládání dat.

Ochrana před SQLi je založena na třech úrovních: použití parametrizovaných dotazů (PreparedStatement v Javě, rawQuery s bindArgs v Androidu), validace vstupních dat na straně klienta a serveru a minimální oprávnění databáze.

Cross-Site Scripting (XSS) ve WebView

XSS útoky v mobilních aplikacích jsou zaměřeny na komponentu WebView — vestavěný prohlížeč, který zobrazuje HTML obsah. Pokud aplikace načítá do WebView data z externích zdrojů bez sanitizace, může útočník vložit JavaScript kód, který se spustí v kontextu aplikace.

Rozlišují se dva podtypy XSS: Stored XSS — škodlivý skript je uložen na serveru a spouští se při každém zobrazení stránky; Reflected XSS — kód je předáván přes URL nebo POST parametry a spouští se jednorázově. V mobilních aplikacích je obzvláště nebezpečný Stored XSS přes komentáře, recenze nebo uživatelský obsah zobrazovaný ve WebView ostatním uživatelům.

Ochrana zahrnuje vypnutí JavaScriptu ve WebView, pokud není vyžadován, použití Content Security Policy (CSP) a sanitizaci HTML obsahu pomocí knihoven jako Jsoup pro Android nebo SwiftSoup pro iOS.

Command Injection přes Intent a Shell

Command Injection — spouštění systémových příkazů na zařízení přes nechráněná volání Runtime.exec(), ProcessBuilder nebo NSTask. V mobilních aplikacích je útok možný, pokud aplikace předává uživatelská data do shell příkazů nebo Intentů s akcemi.

Nejzranitelnější místa jsou funkce konverze souborů, práce s médii (ffmpeg, ImageMagick) a instalace externích knihoven. Útočník může odeslat příkaz se symbolem roury nebo přesměrování, který provede libovolný kód na zařízení. Android částečně omezuje přístup k shellu přes sandbox, ale aplikace s root přístupem nebo PrivEsc exploity mohou být kompromitovány.

Doporučená ochrana — úplné upuštění od Runtime.exec() pro zpracování uživatelských dat, používání knihoven s bezpečným API a přísná izolace externích procesů.

Jak funguje vkládání kódu na Android a iOS

Mechanismus Code Injection se na platformách Android a iOS liší kvůli architektonickým rozdílům. Na Androidu jsou injekce často spojeny s Intent — systémovou zprávou přenášenou mezi komponentami aplikace. Útočník může odeslat škodlivý Intent s extra daty obsahujícími SQL kód nebo shell příkazy.

Na iOS k útokům dochází častěji prostřednictvím mechanismu Interprocess Communication (XPC), Universal Links a zpracování URL Scheme. Aplikace, která přijímá data z externích zdrojů bez kontroly, se stává zranitelnou vůči injekcím. Podle Apple Security Research (2025) souvisí asi 12 % zranitelností v iOS aplikacích s nedostatečnou sanitizací vstupních dat.

Společný vektor pro obě platformy — útok přes lokální úložiště (SQLite, Realm, UserDefaults). Pokud škodlivá aplikace může zapisovat data do sdíleného adresáře, může vložit kód, který bude spuštěn cílovou aplikací při čtení.

Proces typického útoku zahrnuje tři fáze: průzkum — analýza vstupních bodů aplikace (formuláře, deep linky, soubory), injekce — odeslání škodlivého nákladu přes nalezený vstupní bod a zneužití — provedení injekce se získáním přístupu k datům nebo funkcionalitě. Pochopení tohoto cyklu pomáhá vývojáři navrhovat ochranu v každé fázi.

Příklady kódu: zranitelné a zabezpečené implementace

Podívejme se na konkrétní příklady Code Injection v Kotlin pro Android a Swift pro iOS. Každý příklad ukazuje zranitelný vzor a jeho bezpečnou alternativu.

SQL Injection: zranitelný kód v Kotlin

První příklad — přímá konkatenace řetězce dotazu s uživatelským vstupem. Při hodnotě userInput = "1' OR '1'='1" dotaz vrátí všechny řádky tabulky místo jednoho.

// ZRANITELNÉ: konkatenace řetězců
fun getUserById(userInput: String): List<User> {
    val db = openOrCreateDatabase()
    val query = "SELECT * FROM users WHERE id = " + userInput
    return db.rawQuery(query, null)
}

// BEZPEČNÉ: parametrizovaný dotaz
fun getUserByIdSafe(userInput: String): List<User> {
    val db = openOrCreateDatabase()
    val query = "SELECT * FROM users WHERE id = ?"
    return db.rawQuery(query, arrayOf(userInput))
}

XSS ochrana ve WebView: Swift pro iOS

Druhý příklad ukazuje nesprávné a správné načítání uživatelského HTML obsahu ve WKWebView. Použití SwiftSoup umožňuje odstranit škodlivé skripty před zobrazením.

// ZRANITELNÉ: přímé načítání HTML
let webView = WKWebView()
let html = "<div>\(userComment)</div>"
webView.loadHTMLString(html, baseURL: nil)

// BEZPEČNÉ: sanitizace pomocí SwiftSoup
import SwiftSoup
let cleanHtml = try SwiftSoup.clean(
    userComment,
    Whitelist.basic()
)
webView.loadHTMLString(cleanHtml, baseURL: nil)

Command Injection: ochrana před shell útoky v Kotlin

Třetí příklad — nebezpečí volání Runtime.exec() s uživatelskými argumenty a bezpečná alternativa prostřednictvím knihovny s pevným API.

// ZRANITELNÉ: shell příkaz s uživatelským vstupem
fun convertVideo(inputPath: String) {
    val cmd = "ffmpeg -i $inputPath -vcodec libx264 output.mp4"
    Runtime.getRuntime().exec(cmd)
}

// BEZPEČNÉ: izolace argumentů
fun convertVideoSafe(inputPath: String) {
    val cmd = listOf(
        "ffmpeg", "-i", inputPath,
        "-vcodec", "libx264", "output.mp4"
    )
    ProcessBuilder(cmd).start()
}

Metody ochrany mobilních aplikací před injekcemi

Ochrana před Code Injection vyžaduje systematický přístup zahrnující kód, infrastrukturu a vývojové procesy. Žádná jednotlivá metoda nezaručuje úplnou bezpečnost — je nutná kombinace postupů.

První úroveň — prevence: přísná validace všech vstupních dat. Každé pole, které aplikace obdrží od uživatele, jiné aplikace nebo sítě, musí být zkontrolováno na typ, délku a formát. Knihovny jako OWASP ESAPI poskytují hotové validátory pro běžné scénáře.

Druhá úroveň — sanitizace a escapování: transformace dat před jejich použitím v SQL dotazech, HTML šablonách nebo shell příkazech. Parametrizované dotazy zcela eliminují SQL Injection a HTML escapování zabraňuje XSS. Na Androidu pro práci s SQLite používejte Room — ORM, který automaticky aplikuje bind parametry.

Třetí úroveň — minimalizace oprávnění: aplikace by měla pracovat s minimálně nezbytnými právy. Používejte princip nejmenšího oprávnění pro databázi, souborový systém a meziprocesovou komunikaci. iOS implementuje tento princip prostřednictvím sandboxu aplikací a Android — pomocí modelu oprávnění a izolace procesů.

Čtvrtá úroveň — monitorování a reakce: protokolování podezřelých operací, detekce anomálií a automatické blokování při opakovaných útocích. Nástroje jako Firebase App Check pomáhají detekovat falešné požadavky na backend z kompromitovaných klientů. Integrace RASP (Runtime Application Self-Protection) umožňuje blokovat injekce za běhu.

Podle výzkumu Google Project Zero (2025) snižuje kombinace těchto čtyř úrovní riziko úspěšného útoku prostřednictvím Code Injection o 94 %. Vývojářům se doporučuje implementovat ochranné mechanismy ve fázi návrhu architektury, nikoli až po objevení zranitelnosti.