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 з extra-даними, що містять 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-параметри.

Третій рівень — мінімізація привілеїв: додаток має працювати з мінімально необхідними правами. Використовуйте принцип least privilege для бази даних, файлової системи та міжпроцесної взаємодії. iOS реалізує цей принцип через пісочницю додатків, а Android — через permission model та ізоляцію процесів.

Четвертий рівень — моніторинг та реагування: логування підозрілих операцій, виявлення аномалій та автоматичне блокування при повторенні атак. Інструменти на кшталт Firebase App Check допомагають детектувати підроблені запити до бекенду від скомпрометованих клієнтів. Інтеграція RASP (Runtime Application Self-Protection) дозволяє блокувати ін'єкції в рантаймі.

За даними дослідження Google Project Zero (2025), комбінація цих чотирьох рівнів знижує ризик успішної атаки через Code Injection на 94%. Розробникам рекомендується впроваджувати механізми захисту на етапі проєктування архітектури, а не додавати їх після виявлення вразливості.