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%. Разработчикам рекомендуется внедрять механизмы защиты на этапе проектирования архитектуры, а не добавлять их после обнаружения уязвимости.