Методика определения классов уязвимостей мобильных приложений

DOI:

Использование мобильных устройств неуклонно растёт в последние годы. Практически вся деятельность пользователей осуществляется посредством мобильных устройств, включая просмотр новостных ресурсов, проверку электронной почты, обмен сообщениями, совершение покупок в режиме онлайн и осуществление финансовых операций. Однако вместе с ростом популярности мобильных устройств и приложений увеличивается и риск возникновения угроз информационной безопасности. По данным Statista, распространённость мобильных кибератак продолжает расти. В 2024 году 9% всех кибератак в мире были совершены через мобильные устройства. Эта тенденция сохраняется и в последнем квартале 2025 года, когда на мобильных устройствах по всему миру было обнаружено около 440000 вредоносных установочных пакетов. Неисправленные уязвимости являются причиной 60% утечек данных, что делает мобильные приложения серьёзным риском для безопасности [1].

Анализ современных научных публикаций показывает, что проблема классификации и выявления уязвимостей мобильных приложений находится в центре внимания исследовательского сообщества. Так, в работе Shriya Natesan, Lakshmi Natesan Iyer и др. (2020) отмечается, что существующие методы статического анализа часто дают высокий процент ложных срабатываний, что требует разработки более контекстно-ориентированных классификаторов [2]. Исследования Gulshan Shrivastava, Prabhat Kumar (2019) подтверждают, что традиционные веб-ориентированные таксономии уязвимостей плохо адаптируются под специфику мобильных ОС (Android и iOS), где критическую роль играют межпроцессное взаимодействие (IPC) и разрешения манифеста [3]. В отечественной науке вопросы автоматического тестирования безопасности программного обеспечения рассматривается в работе Хусаиновой Э.Р. (2025), которая подчеркивает необходимость автоматизации процессов в разработке программного обеспечения с практиками DevSecOps [4]. В работе Косова Н.А. и Голубничева И.А. подробно рассматривается статистика по уязвимостям безопасности мобильных приложений, в частности, в операционной системе Android и рассмотрены особенности уязвимостей, их риски и способы автоматизированного нахождения уязвимостей в мобильных приложениях. [5] Исследование Войнова А.С. подчеркивают важность защиты информации мобильных приложений в современном мире. [6]

Исходя их изученных научных исследований и работ необходимо создать классификацию уязвимостей для Классификация фундаментальным информационной мобильных уязвимостей элементом безопасности,

приложений. является в области обеспечивая

структурированный подход к идентификации, оценке и управлению рисками, связанными с уязвимостями программного обеспечения, аппаратных систем и сетевых инфраструктур. Системы классификации позволяют унифицировать терминологию, стандартизировать процессы анализа и создать общее понимание угроз среди специалистов, что критически важно для эффективного взаимодействия в рамках глобального сообщества. На сегодняшний день существует множество систем и стандартов, разработанных как международными организациями, так и отраслевыми консорциумами. Каждая из них обладает уникальными характеристиками, целями и методологиями, что обусловливает их применение в различных контекстах. В таблице 1 представлена сравнение систем классификации уязвимостей.

Таблица 1. Сравнение систем классификации уязвимостей.

Table 1. Comparison of vulnerability classification systems.

Система	Область применения	Методология	Преимущества	Недостатки
CVE [7]	Универсальная	Уникальные идентификаторы уязвимостей,      краткое описание	Стандартизация названий, интеграция с инструментами	Нет оценки критичности, требует доп. систем (CVSS)
CVSS [8]	Универсальная	Оценка уязвимостей (0-10) на базе базовых, временных и контекстных метрик	Количественная оценка, приоритизация	Субъективность, сложность адаптации к нишевым отраслям

CWE	Разработка ПО	Каталог слабых мест в коде (SQL-инъекции, переполнение буфера)	Помощь в устранении корневых причин	Избыточная детализация, сложность применения
OWASP Top 10 [9]	Мобильные и вебприложения	Рейтинг топ-10 уязвимостей на основе статистики инцидентов	Практические рекомендации     и простота восприятия	Ограничен      вебсферой,           нет количественных метрик
ГОСТ  Р 569392016 [10]	Гос. ИС	Классификация по типам и уровням критичности, соответствие госстандартам	Учет  национальной специфики, обязательность  для госсектора	Жесткая регламентация, слабая гибкость для бизнеса
СТО  БР ИББС-1.0	Финансовый сектор	Оценка    влияния    на конфиденциальность, целостность, доступность	Адаптация      под регуляторные требования ЦБ РФ	Ограничен банковской сферой
NVD	Универсальная	Агрегация данных CVE с оценками CVSS, списками продуктов и патчей	Полнота данных, интеграция с инструментами	Задержки          в обновлениях,    риск ложных срабатываний
MITRE ATT&CK	Тактики атак	Матрица тактик, техник и процедур (TTPs) злоумышленников	Анализ в контексте поведения атакующих	Частичное дублирование с CWE/ CAPEC,   сложность для новичков
UL 2900	Медицинские IoT	Оценка киберфизических рисков, тестирование на соответствие стандартам	Учет специфики IoT-устройств	Узкая специализация, высокая стоимость сертификации

Российские методики ориентированы на регуляторные требования, но менее гибки. Международные системы (CVE, CVSS) обеспечивают глобальную стандартизацию, но часто игнорируют контекстные особенности конкретных платформ. Специализированные стандарты (например, UL 2900 для IoT) решают нишевые задачи.

Анализ литературы и существующих стандартов выявляет противоречие между необходимостью точного учета специфики мобильных платформ и универсальным характером существующих классификаторов. Целью данной работы является разработка методики определения и классификации уязвимостей, которая сочетает международные практики с требованиями российских регуляторов и учитывает архитектурные особенности мобильных приложений.

МАТЕРИАЛЫ И МЕТОДЫ

Для систематизации процесса выявления и классификации уязвимостей была разработана контекстная диаграмма IDEF0 (Рисунок 1). Данный подход позволяет структурировать этапы анализа, определить входные и выходные данные, а также управляющие факторы и механизмы.

Стандарты

Шкала критичности уязвимостей

Модель классификации уязвимостей

АРК-файлы

IP А-фа илы

Опредтенпе классов уязвимостей мобильных приложении

Отчет с классифицированными уязвимостями

Рекомендации по устранению уязвимостей

Инструменты анализа

Программные Веб-интерфейс средства для формирования отчета

Рисунок 1. Контекстная диаграмма IDEF0.Figure 1. IDEF0 context diagram.

Разработанная методика включает последовательность четырех ключевых этапов (Рисунок 2):

• 1    Извлечение данных. На этом этапе производится сбор артефактов (APK/IPA-файлы, исходный код). Используются инструменты реверс-инжиниринга (apktool, Androguard) для получения манифеста и декомпиляции байт-кода.

• 2    Анализ. Применяется гибридный подход, сочетающий статический (SAST) и

• динамический (DAST) анализ. Механизмом реализации выступают специализированные программные средства, использующие сигнатурный и эвристический методы поиска.

• 3    Определение класса уязвимости. Выявленные аномалии сопоставляются с разработанной моделью классификации и базой знаний (CWE, OWASP).

• 4    Формирование отчета. Генерация итоговых документов с рекомендациями по устранению.

  

  Рисунок 2. Декомпозиция контекстной диаграммы.

  Figure 2. Decomposition of the context diagram.

  
  

РЕЗУЛЬТАТЫ И ОБСУЖДЕНИЯ

Управляющими документами в модели выступают международные стандарты и Методика ФСТЭК от 28.10.2022 «Методика тестирования обновлений безопасности программных, программно-аппаратных средств» [11]. Практическая реализация методики подразумевает использование разработанного программного комплекса для выявления уязвимостей мобильных приложений. Инструмент выполняет парсинг AndroidManifest.xml, анализ Java/Smali кода на наличие опасных паттернов и проверку конфигурационных файлов. Для классификации используется разработанная шкала критичности, адаптирующая метрики CVSS под контекст мобильной разработки.

Рисунок 3. Применение методики.

Figure 3. Application of the technique.

Данная схема показывает этапы реализации методики на практике и отражает последовательность действий. Разработана шкала

уязвимостей

мобильных

представленная в Таблице 2.

приложений,

Таблица 2. Шкала критичности уязвимостей.

Table 2. Vulnerability Criticality Scale.

Критические уязвимости	Высокий риск	Умеренный риск	Низкие риски
Небезопасное хранение конфиденциальных данных	Использование незащищенных протоколов передачи информации	Непреднамеренная компрометация данных	Явные названия компонентов
Небезопасное использование возможностей взаимодействия	Небезопасная конфигурация защищённого соединения	Вывод конфиденциальной информации в системный журнал событий	Избыточные зависимости
Использование небезопасных криптографических методов	Небезопасная аутентификация вебсервера	Небезопасное использование возможностей сети GSM	Логическая утечка через UI

Классификация уязвимостей будет осуществляться по методике ФСТЭК от 28.10.2022 года на основе расчета весовых коэффициентов и оценок показателей.

Уязвимости были классифицированы по функциональной направленности:

• •    использование незащищенных протоколов передачи информации;

• •   небезопасное использование возможностей

межпроцессного взаимодействия;

• •   небезопасная  конфигурация  защищенного

соединения;

• •    небезопасная обработка входных данных;

• •    небезопасная аутентификация веб-сервера;

• •    небезопасное использование возможностей

сети GSM;

• •    использование               небезопасных

криптографических методов;

• •    отсутствие       проверок       наличия

несанкционированного привилегированно доступа к мобильному устройству;

• •   небезопасное хранение конфиденциальных

данных;

• •   недостаточная защита пакета приложения и

• его компонентов;

• •   непреднамеренная компрометация данных;

• •   небезопасная конфигурация и использование

потенциально уязвимых методов в контексте обработки управляемыми ресурсов;

• •    вывод конфиденциальной информации в системный журнал событий.

Это позволяет структурировать анализ и облегчить исправление.

На рисунке 4 представлены функциональные возможности системы.

Рисунок 4. Функциональные возможности.

Figure 4. Functional capabilities.

Модель классификации, представленная в данном разделе, создаёт основу для систематического подхода к выявлению и устранению     уязвимостей,     обеспечивая структурированный анализ и приоритизацию мер защиты. Программный продукт будет выполнять следующие шаги по анализу мобильных приложений:

• •    Разбор AndroidManifest.xml. Извлекается и парсится AndroidManifest.xml (через apktool, при сбоях – через Androguard [12,13]). Из манифеста    собираются    компоненты

приложения (Activities, Services, Receivers, Providers), права, а также флаги (exported, intent f ilters и др.). По этим данным выявляются «избыточные» разрешения и экспортированные            компоненты, потенциально открывающие уязвимости (данные выводятся в отчёте).

• •    Анализ    кода    (Java/Smali).    После

декомпиляции в Java-код (JADX) и разбора smali (apktool [14]) происходит анализ исходного кода на наличие распространённых ошибок. Для Java-кода применяется набор правил (строковые и семантические паттерны) из библиотеки libsast, а также семантический анализ (схожий с semgrep) – например, поиск небезопасных API, устаревших криптоалгоритмов, «жестко» захардкоженных секретов, уязвимых настроек WebView и т.д. Смали-код тоже может анализироваться на сигнатуры (в основном для статической оценки уязвимостей).

Проверка    разрешений    и    политик.

Сравниваются заявленные в манифесте разрешения с характером приложения, помечая «опасные» разрешения (например, android:allowBackup, request_install_packages, проверяется наличие безопасности (Network android:debuggable, и т.п.). Также файлов политик

Security Config) и

другие конфигурации безопасности.

• •    Поиск уязвимостей базируется на множестве правил (поддерживаемых OWASP/Mobile Top10 и собственными). Это поиск небезопасных настроек, слабых алгоритмов, паттернов эксплойтов. Для «вредоносных» сигнатур используется YARA и собственные

правила, а также обращение к базе известных CVE-библиотек.

• •    Отчётность. Все результаты (информация об APK, дерево компонентов, Java-/Smali-код, выводы по каждой категории уязвимостей) аккумулируются Python-кодом и выводятся в веб-интерфейс и формируется PDF-файл для скачивания.

ЗАКЛЮЧЕНИЕ

В ходе исследования была проанализирована выборка мобильных приложений и выявлены наиболее частотные классы уязвимостей. На рисунке 5 представлен график распределения основных категорий угроз [14].

Небезопасное хранение данных 1^- 76%

Передача чувствительных данных в открытом виде ^-35%

Некорректная реализация механизма завершения сессии ^-35%

Небезопасное межпроцессное взаимодействие ^- 29%

Отсутствие механизма защиты Certificate Pinning i^^^^^^^^MI- 29%

Хранение чувствительных данных в исходном коде ^-18%

Недостаточная защита от подбора учетных данных ^-18%

Небезопасная конфигурация приложения Г-- 12%

Возможность использования сторонней клавиатуры

• I—    6%

0%    10%   20%   30%   40%   50%   60%   70%   80%   90%   100%

I Высокий риск

I Средний        Низкий

Рисунок 5. Основные категории уязвимостей, характерных для мобильных приложений.

• Figure 5. Main categories of vulnerabilities typical for mobile applications.

Как видно из диаграммы, доминирующими являются проблемы хранения данных и передачи информации. Рассмотрим подробнее ключевые классы, выявленные в ходе анализа:

• •    Небезопасное хранение данных (76%). Мобильные приложения часто сохраняют данные локально для ускорения работы или офлайн-доступа. Однако недостаточное шифрование или некорректное управление правами доступа (chmod в Linux-based системах Android) приводит к утечкам. Примеры: Хранение токенов аутентификации в открытом виде в SharedPreferences или UserDefaults; кэширование изображений с персональными данными в общедоступных директориях SD-карты; ведение логов, содержащих чувствительную информацию (PII).

• •    Передача чувствительных данных в открытом виде (35%). Вторая по частоте проблема связана с отсутствием   шифрования

транспортного уровня. Использование протокола HTTP вместо HTTPS или некорректная валидация SSL-сертификатов позволяет злоумышленникам реализовать атаки типа Man-in-the-Middle (MitM) и перехватывать трафик.

• •    Небезопасное              межпроцессное

взаимодействие (IPC) (29%). Специфичная для Android уязвимость. Экспортированные компоненты (Activities, Services, Broadcast Receivers), не защищенные разрешениями, могут    быть    вызваны    сторонними вредоносными приложениями. Это приводит к так называемым атакам «confused deputy», когда привилегированное приложение выполняет действия за злоумышленника.

Для систематизации этих угроз была разработана авторская модель классификации. В отличие от общих списков (CVE), она группирует уязвимости по функциональным векторам атаки:

• •    Вектор «Код»: ошибки реализации (Hardcoded secrets, SQL-инъекции).

• •    Вектор     «Платформа»:     небезопасная

конфигурация манифеста, избыточные права.

• •    Вектор «Сеть»:  ошибки SSL Pinning,

использование небезопасных протоколов.

Внедрение данной классификации в разработанный программный инструмент позволило автоматизировать процесс аудита. Тестирование показало, что комбинирование сигнатурного поиска с семантическим анализом кода позволяет выявлять до 85% типовых уязвимостей на этапе CI/CD, что подтверждает эффективность предложенной методики.

Таким образом, методика определения и классификации    уязвимостей    мобильных