Статья Аудит мобильных приложений: полный набор специалиста

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

Аудит - это систематическая проверка и анализ чего-либо с целью выявить косяки, риски, соответствие базе или требованиям. В контексте ИБ, это проверка системы, приложения или сети, чтобы найти уязвимости и повысить их защиту.
Грубо говоря: вне зависимости, чувствуешь ты подвох или нет - ты проверяешь, анализируешь и делаешь выводы.

---

Как все стартовало?

Когда-то, впритык в конец нулевых - мобильные устройства выглядели как карманные компьютеры с ограниченными возможностями. Тогда никто не думал о безопасности - зачем? Они просто были дорогими и редкими, как сейчас оперативка (извините, наболело). Но уже тогда появилась идея - а что если появится психопат и решит вломиться внутрь? Найти уязвимость? Тогда и начался наш путь.

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

Средства аудита были такими же допотопными, как и сама идея. Из основных:

• APKTool, dex2jar, JD-GUI - классика жанра. С их помощью распаковывали APK, вытаскивали и читали байткод, или смотрели, что там внутри. Весь этот процесс - ад современного новомодного СДВГ-шника.
  
  
• Burp Suite, OWASP ZAP - тогда ещё не было их современных версий, нежели именитые ныне имена. Но их аналоги использовали для перехвата трафика. В основном, если речь шла о приложениях с сетевыми взаимодействиями, то перехват и анализ запросов был первым делом.
  
  
• Мануальный анализ кода - да, это было самое важное. Мы сидели и искали ключи под ковриком, пароли, уязвимости типа SQL-инъекций, неправильное управление разрешениями, утечки данных. Рука забивалась, но рука и набивалась.

Со временем появилось больше автоматизированных инструментов - например те, о которых сегодня пойдёт речь. Они значительно ускорили аудит, сделали его системным и менее утомительным. Но суть не изменилась - мы, хакеры и аудиторы, всё равно ищем дырки, даже когда за спиной у нас уже есть крутой "безошибочный" робот.

---

На кой чёрт вообще нужен аудит?​

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

Беда не приходит одна. Если негодяй нашёл рубль, он сделает всё, чтоб найти десять.

Если ты думаешь, что внутренней защиты хватает с головой - эту же голову можешь и выбросить. В большинстве случаев ты только покажешь заинтересованному челу: "Мне до пня на мои данные".

Аудит - это мясной сэт, бронь и меч на +100 к атрибутам, степени защиты твоих клиентов и твоих ресурсов.

Статический стек​

Здесь все зеленушно просто: берете исходники или апк-шки и бьете их базовыми статическими сканерами.

Обязательные инструменты:

MobSF - бесплатный, мощный и понятный. Анализирует как андроиды, так и яблочко, ищет утечки, косяки, плохие конфиги.

Запускаем
Запускай MobSF на локалке или серваке. Быстро, удобно, без лишних заморочек. Это - твоя тестовая лаба.

Загружаем
Залогинься через веб-интерфейс и грузи APK. Вот тут начинается магия. MobSF автоматически распакует, декомпилирует и проанализирует содержимое.

Анализ кода
MobSF делает вышеуказанный статический анализ. Он ищет подозрительные тейки кода, уязвимости, неправильные настройки, API ключи, что ни попадя.
Пример: если в коде есть жестко зашитый API ключ - MobSF отметит. Для негодяя это - как открыть дверь в дом с табличкой "здесь ничё нет".

Обнаружение уязвимостей
MobSF покажет, есть ли у приложения уязвимости в API, неправильные разрешения, использование устаревших библиотек.
Допустим, в приложении обнаружена уязвимость типа инъекции SQL или использование устаревшей библиотеки с известной дырой. Всё это - в отчёте любого удобного тебе формата.

Проверка безопасности API
Если приложение использует REST API, MobSF сможет выделить точки входа и показать, где слабые места - например, отсутствие авторизации или неправильная обработка токенов.

Динамический анализ (по необходимости)
Если хочешь, можешь подключить MobSF к эмулятору или реальному устройству и посмотреть, как приложение ведет себя в реальности - например, перехват трафика через Burp Suite, если есть желание.

Ты получаешь отчёт с перечнем уязвимостей, подсказками, где копать дальше. Не забудь, что MobSF - это автоматизация, а не магия. Важно уметь читать отчёты, понимать контекст. Это твой первый помощник, но не постоянный и не последний.

---

QARK - от Гугла для андроидов, показывает вероятные уязвимости, связанные с API и системой.

Установка
Убедись, что у тебя есть пайтон, джава и все нужные зависимости. Обычно достаточно клонировать репы, установить через pip или запускать через докер-контейнер.
Проще говоря - минимальный сеттинг и ты уже готов к работе.

Запуск
Самое главное - подготовить приложение. Потом запускаешь команду вроде:
qark --apk путь/к/yприложению.apk

или, если хочешь более подробно - с прочими ключами, поищи в man qark/qark --help.

QARK автоматически распарсит APK, декомпилирует его, посмотрит код и найдет потенциальные косяки.

Обзор логов
Через минуту в консоли появится отчёт. Он покажет, например:

• Использование ненадёжных методов,
• Ключи, пароли,
• Уязвимые компоненты,
• Проблемы с инъекциями,
• Внутренние API вызовы с низким уровнем защиты.

Обнаружение конкретных косяков
QARK ищет не просто открытые дырки, а железобетонные тейки - например, неправильное использование инжект- разрешений, или проблемные вызовы API, которые могут быть использованы злоумышленником.

Ручная проверка и эксплойтинг
На основе отчёта ты сразу понимаешь, что именно можно взломать. Например, если есть вызовы WebView с небезопасными настройками, можно попробовать внедрить скрипт или перехватить трафик.

Сильвупле:

• У тебя есть приложуха, ты не дурак, ты запускаешь QARK.
• Получаешь лог с косяками, подсказками где копать дальше. Анализируешь.
• Понимаешь, что делать: фиксить или тестить. Profit.

Но всё же не забывай работать ручками и читать. QARK - хороший стартпоинт, но такой же как и MobSF - не единственный.

---

OWASP Dependency-Check - если используешь сторонние библиотеки, проверь их на наличие известных уязвимостей.

Установка

• Можно установить через Docker, или просто скачать и запустить на машине.
• Для Gradle есть плагины, которые позволяют запускать Dependency-Check прямо из сборки.

Запуск

• Самый быстрый способ - использовать командную строку или встроенный плагин.

Пример с командной строкой:
dependency-check --project "MyAndroidApp" --scan /path/to/your/project

или, если используешь Gradle, можно подключить плагин и запустить:
./gradlew dependencyCheckAnalyze

Результаты
После анализа утилита выдаст отчёт в виде html, xml или json, где будет перечислено:

• Какие библиотеки используются
• Есть ли косяки в этих библиотеках
• Их уровень опасности

Например, ты заметишь, что у тебя библиотека com.squareup.okhttp3:okhttp:3.12.0, которая известна как уязвимая версия.

Плюс - в этих утилитах всё автоматом, быстро, и сразу ясно где копать. Твои ручки зачастую не требуются, но иногда можешь их использовать - не ленись, разбирайся и изучай что там внутри. Покрути справочники.

Минус - ты не получишь тот спектр приколов, который дозволен с ручным анализом и тестингом. Никто не просит тебя заучивать операнды как стишок, но в идеале хотя-бы ознакомиться.

	MobSF	QARK	QWASP-DC
Назначение	Многофункциональный подход к анализу приложений, статический\динамический анализ	Анализ безопасности андроид-бейз приложений, фокус на уязвимостях и эксплойтах	Аналис зависимостей(библиотек), поиск известных уязвимостей
Платформа	Айос, андроид, веб	Андроид	Любая, где есть зависимости
Тип анализа	Статика\динамика\АПИ-анализ\эксплойты	Статика\поиск уязвимостей\эксплоиты	Анализ зависимостей и их уязвимостей
Основные функции	Анализ APK, фулл статический код, уязвимости, АПИ, сертификаты	Анализ APK, поиск эксплойтов и уязвимостей андроид-бейз	Поиск базовых CVE в зависимостях, логи о уязвимостях
Языки	Питон, джава\джаваскрипт	Питон	Джава, очевидно от Dependency-check
Автоматизация	Высокий, интеграция CI\CD	Средний, работа ручками	CI\CD, автологи
Визуал	Терминал, АПИ, вебинтерфейс(через mobsf)	CLI, скрипты	Терминал, логи html\xml
Особенности	Многофункциональный, комплексный	Специализирован на андроид, фокус на эксплойты\уязвимости	Фокус на косяки в зависимостях, автопоиск CVE
Коммьюнити	Активное, широко юзается	Менее активно, но популярно у андроид-пацанвы	Активное, широко юзается

Динамический стек​

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

Инструменты:

Burp Suite - мощный чел для перехвата\изменения\теста трафика, поиска протечек, проверки API. Настраиваешь прокси, делаете тестовые сценарии, кайфуешь не по-детски.

Настройка прокси утилиты

• Запусти Burp Suite и перейди во вкладку сеттинга прокси, затем Intercept, чтобы включить перехват.
• Настрой устройство или эмулятор так, чтобы весь трафик шел через прокси утилиты (обычно это IP-адрес машины с Burp и порт 8080).

Установка сертификата Burp на устройство
Чтобы расшифровать HTTPS-трафик, необходимо установить сертификат Burp на устройство:

• Перейдите с мобильного браузера на
  Ссылка скрыта от гостей
  или
  Ссылка скрыта от гостей
  и скачайте сертификат.
• Установи его как как траст-сертификат (на Android - в настройки безопасности, на iOS - доверие к сертификату).

Перехват трафика

• Запусти приложение.
• В утилите, убедившись, что Intercept включен, ты увидишь запросы и ответы между приложением и серваком.
• Проанализируй: что за API вызывается, какие тейки передаются, есть ли чувствительные данные.

Анализ уязвимостей
Попытайтся изменить параметры запроса. Например:

• Попробуй изменить айди пользователя или параметры логина.
• Посмотрите, есть ли риск SQL-инъекции, или можно ли обойти аутентификацию.

Проверь, криптятся ли данные, есть ли утечки чувствительной инфы.

Использование дополнительных функций

• Используй Repeater для повторных запросов с изменённым сеттингом.
• Используй Intruder для автоматизированных атак, например, перебора паролей(брутфорса) или поиска слабых мест.

Это самый базовый способ понять, защищено ли приложение, насколько безопасна передача данных и есть ли косяки на API-уровне.

---

Frida - фреймворк для динамического анализа, если нужно понять, что приложение делает в реалтайме. Можно подменять функции, искать скрытые вызовы. Ты буквально делаешь софт под микроскопом.

Подготовка​

• У тебя есть мобила или эмулятор с приложением.
• На устройстве\эмуляторе установлен Frida-server (если андроид) или подключен Frida через frida-ios-dump или frida-ios-hook (если аёс).
• Ты запустил frida -U -n com.app.package или через frida-ps -U чтобы найти процесс.

Анализ метода авторизации​

Допустим, в приложении есть функция loginUser(юсернейм, пароль), или она вызывается при нажатии на кнопку входа.

Ты можешь юзать скрипт, который перехватит вызов этой функции и логирует параметры.

Interceptor.attach(Module.findExportByName("libnative.so", "loginUser"), {
  onEnter: function (args) {
    console.log("Вызов loginUser");
    console.log("username: " + Memory.readUtf8String(args[0]));
    console.log("password: " + Memory.readUtf8String(args[1]));
  },
  onLeave: function (retval) {
    console.log("Резулт: " + retval);
  }
});

Это - пример, но зачастую функции могут называться по-другому, или находиться внутри Java/Objective-C методов.

Как итог - ты вставляешь скрипты в риалтайме, логируешь весь функционал, модифицируешь поведение и анализируешь слабое место. Это ключ к живому миру внутри приложения, который поможет понять как оно реально работает, а не как придумано на бумажке.

---

Drozer - для андроида, ищет уязвимости в системе и приложении. Базово - исследование компонентов, поиск эксплойтов и косяков, вызов скрытых апишек и проверка конфига безопасности.

Допустим, у тебя есть Android-приложение, и ты хочешь проверить, есть ли в нем неправильная настройка компонентов или скрытые API, которые могут быть использованы злоумышленником.

Настройка​

• Установи Drozer на свой ПК
• Установи Drozer Agent на устройство или эмулятор
• Запусти Drozer Agent на устройстве/эмуляторе

adb shell am start -n 'com.kaspersky.android.agent/.MainActivity'

или просто drozer console connect

Если все настроено, ты попадешь в интерактивную консоль Drozer.

Получение листа установленных пакетов​

Чтобы понять, какие приложения есть:
run app.package.list

или чтобы проверить, есть ли у конкретного пакета уязвимые компоненты:
run app.package.info -a com.пример.приложения

Анализ компонентов​

Проверка Content Providers​

Для поиска Content Providers (часто используют для хранения данных или взаимодействия):
run app.provider.info -a com.пример.приложения

Это покажет все провайдеры, а также их разрешения.

Проверка Broadcast Receivers​

Чтобы найти Broadcast Receivers, которые могут слушать системные или внутренние мэсседжы:
run app.receiver.info -a com.example.vulnerableapp

​

Вызов скрытых API или эксплойтов​

Есть возможность вызывать методы компонентов или API, если они не защищены качественно. Например, если в приложении есть сервис с командой, который не проверяет энтри-дату:
run app.service.call -a com.example.vulnerableapp -n com.уязвимый.api.SomeApi

или запускать Broadcast:
run app.broadcast.send -a com.пример.приложения-n com.пример.экшена

Если компонент не защищен, можно отправить произвольный мэсседж или вызвать API.

Проверка разрешений и конфигов​

Проверить, какие разрешения запрашиваются приложением:
run app.package.permission.info -a com.пример.приложения

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

Как итог: у тебя на руках неправильно настроенные компоненты, доступ к апишкам(которые не должны быть доступны), тест безопасности и выявленные уязвимости в конфиге приложения.

Тут важно вкурить, как твоё приложение общается с сервером, есть ли там дырки в аутентификации или шифровании.

Проверка API и серверной части​

Многие забывают, что безопасность - это не только то, что внутри приложения, а и то, что оно говорит серверу. Вероятно ты такой же.
Используй Postman или Insomnia для ручных тестов, автоматизируй скриптами. Шевели ручками.

Postman

Пушка. Позволяет отправлять http-запросы, анализировать ответы и автоматизировать процесс теста. В рамках аудита с его помощью можно перехватывать\анализировать API-запросы, стресс-тестить приложение к различным атакам и проверять наличие косяков по линии обработки данных или некорректной проверки логина.

Если API не защищено - клиентам GG, все в пролёте. Представил головняк?

Задача​

Допустим, у тебя есть мобильное приложение, которое взаимодействует с API для получения пользовательских данных, и ты хочешь проверить:

• есть ли возможность получить доступ к чужим даталайнам
• как приложение реагирует на некорректные или изменённые запросы
• есть ли уязвимости типа подделки запросов или отсутствия проверки разрешений

Перехват API-запросов мобильного приложения​

• Используешь инструмент перехвата (например Бёрп, что повыше), чтобы хватать реальные запросы от приложения.
• Анализируешь структуру запросов - URL, параметры, хэдеры, токены.

Воспроизведение запросов в Postman​

• Создаешь в Postman коллекцию и добавляешь туда перехваченные запросы.
• Например, запрос на получение данных пользователя:
  

  GET https://api.example.com/user/profile
  Headers:
  Authorization: Bearer <токен_юзера>

Тест уязвимостей​

1. Проверка авторизации

• Заменяешь токен на левый, чтобы попытаться получить чужие данные.
• Или удаляешь заголовок авторизации - чтобы проверить реакцию API.
• Проверяешь, возвращается ли тру-статус или есть ли возможность доступа без авторизации.

2. Тестирование изменения данных

• Кидаешь пост-запрос с изменёнными значениями операндов (например, меняешь user_id).
• Анализируешь, реагирует ли API на неподдельные запросы или есть ли валид.

3. Подделка токенов

• Создаешь или подделываешь JWT или иные токены, чтобы понять, насколько защищены механизмы логина.
• Проверяешь, есть ли возможность использовать некорректные или старые токены.

Автоматизация и сценки​

Создаешь тесты в Postman, чтобы автоматизировать проверку:

• Ответ сервера на некорректные токены
• Реакцию API на репит попытки
• Проверку, не возвращает ли API лишней инфы

В итоге ты можешь быстро реализовать и редачить реальные апи-запросы и выявлять косяки в механизмах логина и проверки данных. Не только ручками: автоматизация тоже для тебя не проблема, включая автоповтор тестов безопасности. Интеграция чеков в CI\CD - как вишенка на тортике автоматизации.

---

Insomnia

Аналог предыдущей пушки, особо неотличимый. Аналогичные запросы на веб-уровне, их сохранение, автоматизация и анализ. В аудите аналогично незаменимо: перехват и воспроизведение, проверка косяков авторизации\аутентификации, стресс-тесты и выявление утечек.

Задача​

Допустим, ты надеваешь маску негодяя и хочешь проверить, насколько защищены API-методы для получения данных юзера. В частности, проверить, есть ли возможность получить доступ к чужим данным или выполнить запрос без правильных разрешений.

Перехват из мобильного приложения​

• Используешь Бёрп и его аналоги, чтобы поймать запрос при использовании мобильного приложения.
• Так же изучаешь структуру: URL, HTTP-метод, хэдеры, параметры, токены авторизации.

Воспроизведение запросов​

• Создаёшь в Insomnia новый запрос в проекте. Например, запрос на получение профиля пользователя:
  
  

  GET https://api.example.com/user/profileHeaders:
  Authorization: Bearer <токен_пользователя>

• Сохраняешь его для дальнейших тестов.

Тест уязвимостей​

1. Проверка авторизации

• Меняешь токен на другой (например, токен другого юзера).
• Посылаешь запрос - проверяешь, в руках ли чужие данные.
• Удаляешь или изменяешь заголовок Authorization - чтобы проверить, блокируется ли доступ без токена.

2. Тестирование подделки запросов

• Меняешь параметры в запросе (например, user_id или другие параметры) для попытки обойти границы сеттинга.
• Проверяешь, реагирует ли API на эти негодяйства или есть ли валид.

3. Проверка реакции API на некорректные или просроченные токены

• Отправляешь запрос с косячным токеном.
• Анализируешь, нормально ли API сообщает об ошибке, и не возвращает ли лишних данных.

Автоматизация и создание сцен​

• Создаёшь тестовые сценарии внутри Insomnia или с помощью интеграций, чтобы автоматически проверять реакции API при разных условиях.
• Настраиваешь робота-раба на процесс тестов на ответы, проверяющие статускоды, содержимое и безопасность данных.

Особо ничего нового в сравнении с парнем выше. Аналогично тестинг механизмов, автоматизация, тритхантинг, воспроизведение запросов.

Кратко о будущем и тенденциях аудита​

• Искусство аудита не стоит на месте: всё больше утилит интегрируются в процессы автоматических тестов и пайплайны CI\CD. Автоматизация анализа кода, поиска уязвимостей и статический анализ вскоре станут международным стандартом.
  
  
• Ко всему прочему, не дают пропасть и нейросети. Рободурак начинает помогать выявлять потенциальные косяки и аномалии точнее и быстрее, автоматически классифицируя угрозы и расставляя приоритеты рисков без вмешательства человека.
  
  
• Всё больше внимания уделяется поведению приложений в жизненной среде, эмуляции и симуляции атак.
  
  
• Вендорами поднимается вопрос о критической важности защиты API-уровня, который всё чаще и чаще становится центральным в мобильных приложениях.
  
  
• Мощнейшие платформы интегрируются для масштабных тестирований, эмуляций, проб атак и анализа. Их вычислительные показатели делают работу аудиторов в разы качественнее.
  
  
• Серверная часть, последняя из тех, что мы обсудили, тоже в центре внимания: бэкенд-инфраструктура активно тестируется и перерабатывается для достижения всё больших профитов.

Положение дел не может не радовать, наша безопасность усиливается и нам, специалистам, остается только наблюдать, изучать и подстраиваться.

---

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

Безопасность - это не разовая акция, а процесс без конца и края.
Обновляй, проверяй, ищи слабые места. Ты спортсмен. Выполняй нормативы и будь близок к трофеям.

Если хочешь трушно защититься - не верь рекламе, не слушай сказки, делай честный аудит. Всё остальное - мифы.

Намотай на ус. Нет усов - твои проблемы.​