Code Injection w aplikacjach mobilnych — co to jest, rodzaje ataków i ochrona

Czym jest Code Injection?

Code Injection — klasa ataków, w których osoba atakująca wstrzykuje wykonywalny kod do aplikacji przez niezaufane dane wejściowe. W aplikacjach mobilnych atak jest możliwy przez pola wprowadzania, deep linki, powiadomienia push, kody QR i wymianę plików.

W przeciwieństwie do ataków na poziomie systemu operacyjnego, Code Injection wykorzystuje błędy logiczne w kodzie samej aplikacji: brak ekranowania, niebezpieczną konkatenację ciągów znaków lub zaufanie do zewnętrznych źródeł danych. Według raportu Positive Technologies (2025), iniekcje stanowią 23% wszystkich podatności w aplikacjach mobilnych sektora finansowego.

Główne zagrożenie Code Injection — całkowita kompromitacja danych: osoba atakująca może uzyskać dostęp do bazy danych, systemu plików urządzenia lub kont innych użytkowników. Dla aplikacji mobilnych pracujących z danymi płatniczymi lub informacjami medycznymi konsekwencje mogą być krytyczne.

Programista musi rozumieć rodzaje iniekcji i stosować mechanizmy ochronne na wszystkich poziomach — od wprowadzania danych po ich wyświetlanie i przechowywanie. Nowoczesne frameworki zapewniają wbudowane środki ochrony, ale ich użycie wymaga świadomego podejścia.

Główne rodzaje Code Injection w aplikacjach mobilnych

Klasyfikacja Code Injection obejmuje trzy główne typy ataków w kontekście tworzenia aplikacji mobilnych. Każdy typ wykorzystuje różne komponenty aplikacji i wymaga specyficznych metod ochrony.

SQL Injection w aplikacjach mobilnych

SQL Injection (SQLi) — wstrzyknięcie złośliwego kodu SQL przez parametry zapytań do lokalnej lub zdalnej bazy danych. W aplikacjach mobilnych podatność występuje przy niebezpiecznej pracy z SQLite na urządzeniu lub przy tworzeniu zapytań HTTP do REST API z konkatenacją ciągów.

Typowy wektor ataku — pole wyszukiwania lub filtrowania, którego wartość jest podstawiana bezpośrednio do zapytania SQL. Jeśli programista używa surowej konkatenacji zamiast zapytań parametryzowanych, osoba atakująca może przekazać ciąg 1' OR '1'='1. Według danych OWASP Mobile Top 10 (2024), SQL Injection pozostaje drugą najczęstszą krytyczną podatnością w aplikacjach mobilnych w kategorii niebezpiecznego przechowywania danych.

Ochrona przed SQLi opiera się na trzech poziomach: używanie zapytań parametryzowanych (PreparedStatement w Javie, rawQuery z bindArgs w Android), walidacja danych wejściowych po stronie klienta i serwera oraz minimalne uprawnienia bazy danych.

Cross-Site Scripting (XSS) w WebView

Ataki XSS w aplikacjach mobilnych są skierowane na komponent WebView — wbudowaną przeglądarkę, która wyświetla zawartość HTML. Jeśli aplikacja ładuje do WebView dane z zewnętrznych źródeł bez sanityzacji, osoba atakująca może wstrzyknąć kod JavaScript, który wykona się w kontekście aplikacji.

Wyróżnia się dwa podtypy XSS: Stored XSS — złośliwy skrypt jest przechowywany na serwerze i wykonuje się przy każdym wyświetleniu strony, oraz Reflected XSS — kod jest przesyłany przez URL lub parametry POST i wykonuje się jednorazowo. W aplikacjach mobilnych szczególnie niebezpieczny jest Stored XSS przez komentarze, opinie lub treści użytkowników wyświetlane w WebView innym użytkownikom.

Ochrona obejmuje wyłączenie JavaScript w WebView, jeśli nie jest wymagany, użycie Content Security Policy (CSP) oraz sanityzację treści HTML przez biblioteki takie jak Jsoup dla Android lub SwiftSoup dla iOS.

Command Injection przez Intent i Shell

Command Injection — wykonywanie poleceń systemowych na urządzeniu przez niepoprawnie wywołane Runtime.exec(), ProcessBuilder lub NSTask. W aplikacjach mobilnych atak jest możliwy, jeśli aplikacja przekazuje dane użytkownika do poleceń shell lub Intent-ów z akcjami.

Najbardziej podatne miejsca to funkcje konwersji plików, pracy z mediami (ffmpeg, ImageMagick) i instalacji bibliotek zewnętrznych. Osoba atakująca może przekazać polecenie ze znakiem potoku lub przekierowania, które wykona dowolny kod na urządzeniu. Android częściowo ogranicza dostęp do shell przez piaskownicę (sandbox), ale aplikacje z root-dostępem lub exploitami PrivEsc mogą być skompromitowane.

Zalecana ochrona — całkowita rezygnacja z Runtime.exec() do przetwarzania danych użytkownika, używanie bibliotek z bezpiecznym API i ścisła izolacja procesów zewnętrznych.

Jak działa wstrzykiwanie kodu na Android i iOS

Mechanizm Code Injection różni się na platformach Android i iOS ze względu na różnice architektoniczne. Na Android iniekcje często związane są z Intent — komunikatem systemowym przesyłanym między komponentami aplikacji. Osoba atakująca może wysłać złośliwy Intent z danymi extra zawierającymi kod SQL lub polecenia shell.

Na iOS ataki częściej występują przez mechanizm Interprocess Communication (XPC), Universal Links i obsługę URL Scheme. Aplikacja, która przyjmuje dane z zewnętrznych źródeł bez sprawdzenia, staje się podatna na iniekcje. Według danych Apple Security Research (2025), około 12% podatności w aplikacjach iOS związanych jest z niedostateczną sanityzacją danych wejściowych.

Wspólny dla obu platform wektor — atak przez lokalne przechowywanie danych (SQLite, Realm, UserDefaults). Jeśli złośliwa aplikacja może zapisać dane do wspólnego katalogu, może wstrzyknąć kod, który zostanie wykonany przez docelową aplikację podczas odczytu.

Proces typowego ataku obejmuje trzy etapy: rozpoznanie — analiza punktów wejścia aplikacji (formularze, deep linki, pliki), iniekcja — przekazanie złośliwego ładunku przez znaleziony punkt wejścia i eksploatacja — wykonanie iniekcji z uzyskaniem dostępu do danych lub funkcjonalności. Zrozumienie tego cyklu pomaga programiście projektować ochronę na każdym etapie.

Przykłady kodu: podatne i bezpieczne implementacje

Rozważmy konkretne przykłady Code Injection w Kotlin dla Android i Swift dla iOS. Każdy przykład pokazuje podatny wzorzec i jego bezpieczną alternatywę.

SQL Injection: podatny kod w Kotlin

Pierwszy przykład — bezpośrednia konkatenacja ciągu zapytania z danymi wejściowymi użytkownika. Przy wartości userInput = "1' OR '1'='1" zapytanie zwróci wszystkie wiersze tabeli zamiast jednego.

// PODATNE: konkatenacja ciągów
fun getUserById(userInput: String): List<User> {
    val db = openOrCreateDatabase()
    val query = "SELECT * FROM users WHERE id = " + userInput
    return db.rawQuery(query, null)
}

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

Ochrona XSS w WebView: Swift dla iOS

Drugi przykład demonstruje nieprawidłowe i prawidłowe ładowanie treści HTML użytkownika w WKWebView. Użycie SwiftSoup pozwala usunąć złośliwe skrypty przed wyświetleniem.

// PODATNE: bezpośrednie ładowanie HTML
let webView = WKWebView()
let html = "<div>\(userComment)</div>"
webView.loadHTMLString(html, baseURL: nil)

// BEZPIECZNE: sanityzacja przez SwiftSoup
import SwiftSoup
let cleanHtml = try SwiftSoup.clean(
    userComment,
    Whitelist.basic()
)
webView.loadHTMLString(cleanHtml, baseURL: nil)

Command Injection: ochrona przed atakami shell na Kotlin

Trzeci przykład — zagrożenie wywołania Runtime.exec() z argumentami użytkownika i bezpieczna alternatywa przez bibliotekę ze stałym API.

// PODATNE: polecenie shell z danymi użytkownika
fun convertVideo(inputPath: String) {
    val cmd = "ffmpeg -i $inputPath -vcodec libx264 output.mp4"
    Runtime.getRuntime().exec(cmd)
}

// BEZPIECZNE: izolacja argumentów
fun convertVideoSafe(inputPath: String) {
    val cmd = listOf(
        "ffmpeg", "-i", inputPath,
        "-vcodec", "libx264", "output.mp4"
    )
    ProcessBuilder(cmd).start()
}

Metody ochrony aplikacji mobilnych przed iniekcjami

Ochrona przed Code Injection wymaga systematycznego podejścia obejmującego kod, infrastrukturę i procesy tworzenia. Żadna pojedyncza metoda nie gwarantuje pełnego bezpieczeństwa — konieczna jest kombinacja praktyk.

Pierwszy poziom — zapobieganie: ścisła walidacja wszystkich danych wejściowych. Każde pole, które aplikacja otrzymuje od użytkownika, innej aplikacji lub sieci, powinno być sprawdzone pod kątem typu, długości i formatu. Biblioteki takie jak OWASP ESAPI zapewniają gotowe walidatory dla typowych scenariuszy.

Drugi poziom — sanityzacja i ekranowanie: przekształcanie danych przed ich użyciem w zapytaniach SQL, szablonach HTML lub poleceniach shell. Zapytania sparametryzowane całkowicie eliminują SQL Injection, a ekranowanie HTML zapobiega XSS. Na Android do pracy z SQLite używaj Room — ORM, który automatycznie stosuje parametry bind.

Trzeci poziom — minimalizacja uprawnień: aplikacja powinna działać z minimalnie niezbędnymi prawami. Stosuj zasadę najmniejszego uprzywilejowania dla bazy danych, systemu plików i komunikacji międzyprocesowej. iOS implementuje tę zasadę przez piaskownicę aplikacji, a Android — przez model uprawnień i izolację procesów.

Czwarty poziom — monitorowanie i reagowanie: rejestrowanie podejrzanych operacji, wykrywanie anomalii i automatyczne blokowanie przy powtarzających się atakach. Narzędzia takie jak Firebase App Check pomagają wykrywać fałszywe zapytania do backendu od skompromitowanych klientów. Integracja RASP (Runtime Application Self-Protection) pozwala blokować iniekcje w czasie wykonywania.

Według danych badania Google Project Zero (2025), kombinacja tych czterech poziomów zmniejsza ryzyko udanego ataku przez Code Injection o 94%. Programistom zaleca się wdrażanie mechanizmów ochrony na etapie projektowania architektury, a nie dodawanie ich po wykryciu podatności.