Code Injection в мобилните приложения — какво е, видове атаки и защита

Какво е Code Injection?

Code Injection — клас атаки, при които нападателят инжектира изпълним код в приложението чрез ненадеждни входни данни. В мобилните приложения атаката е възможна чрез полета за въвеждане, deep link-ове, push известия, QR кодове и обмен на файлове.

За разлика от атаките на ниво операционна система, Code Injection използва логически грешки в кода на самото приложение: липса на екраниране, небезопасно конкатениране на низове или доверие към външни източници на данни. Според доклад на Positive Technologies (2025), инжекциите съставляват 23% от всички уязвимости в мобилните приложения на финансовия сектор.

Основната опасност от Code Injection — пълно компрометиране на данни: нападателят може да получи достъп до базата данни, файловата система на устройството или акаунтите на други потребители. За мобилни приложения, работещи с платежни данни или медицинска информация, последствията могат да бъдат критични.

Разработчикът трябва да разбира видовете инжекции и да прилага защитни механизми на всички нива — от въвеждане на данни до тяхното показване и съхранение. Съвременните рамки предоставят вградени защитни средства, но тяхното използване изисква съзнателен подход.

Основни видове Code Injection в мобилните приложения

Класификацията на Code Injection включва три основни вида атаки в контекста на мобилната разработка. Всеки вид използва различни компоненти на приложението и изисква специфични методи за защита.

SQL Injection в мобилни приложения

SQL Injection (SQLi) — инжектиране на зловреден SQL код чрез параметри на заявки към локална или отдалечена база данни. В мобилните приложения уязвимостта възниква при небезопасна работа с SQLite на устройството или при изграждане на HTTP заявки към REST API с конкатенация на низове.

Типичен вектор на атака — поле за търсене или филтриране, чиято стойност се вмъква директно в SQL заявката. Ако разработчикът използва сурова конкатенация вместо параметризирани заявки, нападателят може да предаде низ като 1' OR '1'='1. Според OWASP Mobile Top 10 (2024), SQL Injection остава втората най-честа критична уязвимост в мобилните приложения в категорията на небезопасно съхранение на данни.

Защитата срещу SQLi се основава на три нива: използване на параметризирани заявки (PreparedStatement в Java, rawQuery с bindArgs в Android), валидация на входните данни от страна на клиента и сървъра и минимални привилегии на базата данни.

Cross-Site Scripting (XSS) в WebView

XSS атаките в мобилните приложения са насочени към компонента WebView — вградения браузър, който показва HTML съдържание. Ако приложението зарежда в WebView данни от външни източници без санитизация, нападателят може да инжектира JavaScript код, който ще се изпълни в контекста на приложението.

Различават се два подтипа XSS: Stored XSS — зловредният скрипт се съхранява на сървъра и се изпълнява при всяко преглеждане на страницата; Reflected XSS — кодът се предава чрез URL или POST параметри и се изпълнява еднократно. В мобилните приложения Stored XSS чрез коментари, ревюта или потребителско съдържание, показвано в WebView на други потребители, е особено опасен.

Защитата включва изключване на JavaScript в WebView, ако не е необходим, използване на Content Security Policy (CSP) и санитизация на HTML съдържание чрез библиотеки като Jsoup за Android или SwiftSoup за iOS.

Command Injection чрез Intent и Shell

Command Injection — изпълнение на системни команди на устройството чрез незащитени извиквания на Runtime.exec(), ProcessBuilder или NSTask. В мобилните приложения атаката е възможна, ако приложението предава потребителски данни на shell команди или Intent-и с действия.

Най-уязвимите места са функциите за конвертиране на файлове, работа с медии (ffmpeg, ImageMagick) и инсталиране на външни библиотеки. Нападателят може да предаде команда със символ на тръба или пренасочване, която ще изпълни произволен код на устройството. Android частично ограничава достъпа до shell чрез пясъчна кутия (sandbox), но приложения с root достъп или PrivEsc експлойти могат да бъдат компрометирани.

Препоръчителна защита — пълно отказване от Runtime.exec() за обработка на потребителски данни, използване на библиотеки със защитен API и строга изолация на външни процеси.

Как работи инжектирането на код на Android и iOS

Механизмът на Code Injection се различава на платформите Android и iOS поради архитектурни различия. На Android инжекциите често са свързани с Intent — системно съобщение, което се предава между компонентите на приложението. Нападателят може да изпрати зловреден Intent с допълнителни данни, съдържащи SQL код или shell команди.

На iOS атаките се случват по-често чрез механизма Interprocess Communication (XPC), Universal Links и обработка на URL Scheme. Приложение, което приема данни от външни източници без проверка, става уязвимо за инжекции. Според Apple Security Research (2025), около 12% от уязвимостите в iOS приложенията са свързани с недостатъчна санитизация на входните данни.

Общ вектор за двете платформи — атака чрез локално хранилище (SQLite, Realm, UserDefaults). Ако зловредно приложение може да запише данни в споделена директория, то може да инжектира код, който ще бъде изпълнен от целевото приложение при четене.

Процесът на типична атака включва три етапа: разузнаване — анализ на входните точки на приложението (форми, deep link-ове, файлове), инжектиране — предаване на зловредния товар чрез намерената входна точка и експлоатация — изпълнение на инжекцията с получаване на достъп до данни или функционалност. Разбирането на този цикъл помага на разработчика да проектира защита на всеки етап.

Примери за код: уязвими и защитени реализации

Нека разгледаме конкретни примери за Code Injection в Kotlin за Android и Swift за iOS. Всеки пример показва уязвим модел и неговата защитена алтернатива.

SQL Injection: уязвим код в Kotlin

Първият пример — директно конкатениране на низа на заявката с потребителския вход. При стойност userInput = "1' OR '1'='1" заявката ще върне всички редове на таблицата вместо един.

// УЯЗВИМО: конкатенация на низове
fun getUserById(userInput: String): List<User> {
    val db = openOrCreateDatabase()
    val query = "SELECT * FROM users WHERE id = " + userInput
    return db.rawQuery(query, null)
}

// БЕЗОПАСНО: параметризирана заявка
fun getUserByIdSafe(userInput: String): List<User> {
    val db = openOrCreateDatabase()
    val query = "SELECT * FROM users WHERE id = ?"
    return db.rawQuery(query, arrayOf(userInput))
}

XSS защита в WebView: Swift за iOS

Вторият пример демонстрира неправилно и правилно зареждане на потребителско HTML съдържание в WKWebView. Използването на SwiftSoup позволява премахване на зловредни скриптове преди показване.

// УЯЗВИМО: директно зареждане на HTML
let webView = WKWebView()
let html = "<div>\(userComment)</div>"
webView.loadHTMLString(html, baseURL: nil)

// БЕЗОПАСНО: санитизация чрез SwiftSoup
import SwiftSoup
let cleanHtml = try SwiftSoup.clean(
    userComment,
    Whitelist.basic()
)
webView.loadHTMLString(cleanHtml, baseURL: nil)

Command Injection: защита от shell атаки в Kotlin

Третият пример — опасността от извикване на Runtime.exec() с потребителски аргументи и защитената алтернатива чрез библиотека с фиксирано API.

// УЯЗВИМО: shell команда с потребителски вход
fun convertVideo(inputPath: String) {
    val cmd = "ffmpeg -i $inputPath -vcodec libx264 output.mp4"
    Runtime.getRuntime().exec(cmd)
}

// БЕЗОПАСНО: изолация на аргументи
fun convertVideoSafe(inputPath: String) {
    val cmd = listOf(
        "ffmpeg", "-i", inputPath,
        "-vcodec", "libx264", "output.mp4"
    )
    ProcessBuilder(cmd).start()
}

Методи за защита на мобилни приложения от инжекции

Защитата от Code Injection изисква систематичен подход, обхващащ кода, инфраструктурата и процесите на разработка. Нито един отделен метод не гарантира пълна сигурност — необходима е комбинация от практики.

Първо ниво — предотвратяване: строга валидация на всички входни данни. Всяко поле, което приложението получава от потребителя, друго приложение или мрежата, трябва да бъде проверено за тип, дължина и формат. Библиотеки като OWASP ESAPI предоставят готови валидатори за често срещани сценарии.

Второ ниво — санитизация и екраниране: трансформиране на данните преди използването им в SQL заявки, HTML шаблони или shell команди. Параметризираните заявки напълно елиминират SQL Injection, а HTML екранирането предотвратява XSS. На Android за работа с SQLite използвайте Room — ORM, който автоматично прилага bind параметри.

Трето ниво — минимизиране на привилегиите: приложението трябва да работи с минимално необходимите права. Прилагайте принципа на най-малката привилегия за базата данни, файловата система и междупроцесната комуникация. iOS реализира този принцип чрез пясъчна кутия на приложенията, а Android — чрез модела на разрешения и изолация на процеси.

Четвърто ниво — мониторинг и реагиране: записване на подозрителни операции, откриване на аномалии и автоматично блокиране при повтарящи се атаки. Инструменти като Firebase App Check помагат за откриване на фалшиви заявки към backend от компрометирани клиенти. Интеграцията на RASP (Runtime Application Self-Protection) позволява блокиране на инжекции в реално време.

Според изследване на Google Project Zero (2025), комбинацията от тези четири нива намалява риска от успешна атака чрез Code Injection с 94%. Препоръчва се на разработчиците да внедряват защитни механизми на етапа на проектиране на архитектурата, а не след откриване на уязвимост.