Представьте: приложение банка проходит пентест, все проверки зелёные, а через месяц выясняется, что токены доступа хранились в открытом виде в SharedPreferences. Или другой случай: разработчики включили SSL pinning, но только для основного домена, а API для загрузки файлов осталось без защиты. Такие истории — не редкость. Безопасность мобильных приложений кажется простой, пока не столкнёшься с реальным устройством, где всё работает иначе, чем на эмуляторе.
В этой статье разберём, почему Mobile Security — это отдельная дисциплина, а не просто «ещё один раздел веб-безопасности». Покажем на примере, как практик ищет уязвимости, какие режимы отказа встречаются чаще всего и кому действительно нужно осваивать эту область — а кому будет пустой тратой времени.
Почему мобильная безопасность — это не «веб, но поменьше»
Мобильное приложение — это не сайт в миниатюре. Здесь другой ландшафт угроз: код хранится на устройстве, которое пользователь может полностью контролировать (root, джейлбрейк), трафик можно перехватить через прокси, а reverse engineering (реверс-инжиниринг) позволяет восстановить логику даже из обфусцированного бинарника. В вебе вы не отдаёте клиенту серверный код, а в мобильном приложении — отдаёте, и он должен быть защищён.
Ключевое отличие — модель доверия. В вебе сервер доверяет только себе, а в мобильном приложении клиент и сервер постоянно обмениваются данными, и клиент может быть скомпрометирован. Поэтому все проверки, которые выполняются на устройстве (например, проверка подписи или root-прав), можно обойти с помощью инструментов вроде Frida. Это порождает целый класс атак, которых нет в вебе: подмена кода на лету, перехват и модификация трафика, дамп памяти.
Ещё один важный аспект — фрагментация платформ. iOS и Android имеют разные механизмы безопасности: на iOS это code signing и песочница, на Android — разрешения, SELinux и Verified Boot. Инструменты тоже различаются: для Android используют APKTool, MobSF, Drozer, для iOS — class-dump, Cycript, Frida. Специалист должен уметь работать с обеими платформами или хотя бы понимать их различия.
Как на самом деле выглядит поиск уязвимостей: разбор одной задачи
Допустим, перед нами Android-приложение интернет-магазина. Задача — проверить, может ли злоумышленник получить доступ к API от имени другого пользователя. Начинаем с анализа трафика: настраиваем Burp Suite как прокси на эмуляторе, устанавливаем сертификат Burp в системное хранилище (на эмуляторе это возможно, на реальном устройстве без root — нет). Запускаем приложение и видим, что трафик идёт, но часть запросов не расшифровывается — приложение использует SSL pinning.
Первый шаг — обойти pinning. Для этого используем Frida и скрипт, который перехватывает функции проверки сертификата. Например, для OkHttp3 это будет CertificatePinner.check(). Загружаем скрипт через frida -U -f com.example.app -l bypass.js. Если всё сделано правильно, трафик начинает проходить через прокси в открытом виде. Но здесь часто ошибаются: забывают, что некоторые библиотеки (например, TrustKit) могут использовать нативные проверки, и тогда нужен другой подход — патчинг APK через apktool и пересборка.
После обхода pinning анализируем запросы. Видим, что авторизация происходит по токену в заголовке Authorization. Пробуем изменить тело запроса: например, заменить userId в запросе на другой. Если API не проверяет, что токен принадлежит этому userId, — это IDOR (Insecure Direct Object Reference), одна из уязвимостей из OWASP Mobile Top 10. В реальном кейсе такое приводило к тому, что любой пользователь мог читать заказы других, зная только их идентификатор.
Далее проверяем хранение данных. С помощью MobSF делаем статический анализ APK: смотрим, не хранятся ли пароли или токены в SharedPreferences или в локальной базе SQLite в открытом виде. Часто разработчики используют EncryptedSharedPreferences, но ключ шифрования может быть статическим или производным от простого пароля. Если находим токен в открытом виде — это критическая уязвимость.
Что пойдёт не так, если делать иначе? Если пропустить этап обхода pinning и сразу перейти к статическому анализу, можно не увидеть, какие данные передаются в API, и упустить логические уязвимости. Если не проверить API на IDOR, можно дать ложное заключение о безопасности. Наконец, если тестировать только на эмуляторе, можно не заметить защиту, которая срабатывает только на реальном устройстве (например, проверка наличия root).
Где ломается защита: типичные режимы отказа
В мобильной безопасности есть несколько сценариев, в которых даже правильно задуманные механизмы перестают работать. Рассмотрим самые частые.
1. SSL pinning, который легко обойти
Пиннинг сертификата — популярная мера, но многие реализуют его только для основного домена, забывая про CDN или API для загрузки файлов. Или используют устаревшие библиотеки с известными багами. Как заметить заранее: проведите трафик через прокси и посмотрите, какие домены остаются незашифрованными. Если видите, что запросы к api.example.com идут через прокси без ошибок, а к cdn.example.com — нет, значит, пиннинг неполный. Что делать: внедрить пиннинг на уровне сетевого стека (например, через Network Security Config в Android) для всех доменов, включая сторонние SDK.
2. Обфускация, которая не мешает реверсу
Разработчики включают ProGuard или R8, но забывают, что имена классов и методов все равно можно восстановить по строкам, ресурсам или вызовам API. Frida позволяет перехватывать методы по сигнатуре, даже если имена обфусцированы. Как заметить: попробуйте найти в декомпилированном коде строки, содержащие ключи или URL, — часто они остаются в открытом виде. Что делать: использовать более стойкую обфускацию (например, DexGuard) и избегать хранения секретов в коде.
3. Проверки на root, которые обходятся одним скриптом
Многие приложения проверяют наличие root или джейлбрейка, но делают это через простые проверки файлов (/system/app/Superuser.apk). Frida позволяет подменить результат любой функции, возвращающей булево значение. Как заметить: если приложение падает или ведёт себя странно на рутованном устройстве, но при этом не блокирует основные функции — проверка неэффективна. Что делать: использовать несколько уровней проверки (SafetyNet Attestation, проверка целостности APK) и не полагаться только на клиентские проверки.
4. Безопасность API, которая заканчивается на клиенте
Часто разработчики думают, что если в приложении есть проверка прав, то API защищён. Но API можно вызвать напрямую, минуя приложение. Например, если приложение проверяет, что пользователь — админ, и только потом показывает кнопку удаления, но API не проверяет права при вызове метода удаления, — это уязвимость. Как заметить: проанализируйте запросы и попробуйте выполнить действия, недоступные в интерфейсе. Что делать: всегда дублировать проверки на сервере.
Пути освоения: самостоятельный, курсы, практика
Освоить мобильную безопасность можно по-разному. Самый доступный путь — самостоятельный: читать документацию OWASP Mobile Security Testing Guide, смотреть записи конференций, проходить лаборатории на Hack The Box или PentesterLab. Плюсы: бесплатно или дёшево, гибкий график. Минусы: нет обратной связи, легко упустить важные детали, ошибки в пентесте могут привести к ложным выводам.
Второй путь — курсы. Они дают структуру, практические задания и разбор ошибок. Например, курс «Mobile Security — безопасность мобильных приложений (iOS и Android)» на asibiont.com включает работу с MobSF, Frida, Objection, Burp Suite и другими инструментами. Обучение построено на персонализированных уроках, которые адаптируются под уровень студента. Но курсы требуют времени и денег, и не все дают глубокую практику на реальных устройствах.
Третий путь — практика в компании или на фрилансе. Самый эффективный, но требует начальных навыков и часто недоступен новичкам. Можно начать с bug bounty: искать уязвимости в мобильных приложениях на платформах вроде HackerOne. Это даёт реальный опыт и обратную связь, но конкуренция высока.
Trade-off: самостоятельное обучение дешевле, но медленнее и с риском пробелов. Курсы быстрее и структурированнее, но стоят денег. Практика даёт лучший результат, но требует базовой подготовки.
Кому подходит этот путь, а кому нет
Mobile Security — не для всех. Вот критерии, которые помогут решить.
Подходит, если вы:
- Разработчик мобильных приложений (iOS или Android) и хотите понимать, как защитить свой код.
- Специалист по информационной безопасности, желающий расширить экспертизу на мобильные платформы.
- Тестировщик, который хочет перейти в пентест и ищет специализацию.
- Студент технической специальности с базовыми знаниями ОС и сетей.
Не подходит, если вы:
- Совсем новичок в IT и не знакомы с основами Linux, сетей и программирования. Без этого будет слишком сложно.
- Ожидаете, что курс сделает вас экспертом за неделю. Мобильная безопасность требует практики и времени.
- Не готовы работать с реальными устройствами и инструментами, которые могут привести к блокировке устройства (например, root).
Если вы попадаете в первую категорию, стоит начать с основ: изучите OWASP Mobile Top 10, попробуйте пройти лаборатории на PortSwigger (они есть и для мобильных приложений). Затем переходите к практике с Frida и MobSF.
Курс «Mobile Security — безопасность мобильных приложений (iOS и Android)» даёт структурированный путь: от анализа трафика до реверс-инжиниринга и защиты API. Он будет полезен тем, кто хочет систематизировать знания и получить обратную связь по практическим заданиям. Подробности и запись — на странице курса: Mobile Security — безопасность мобильных приложений (iOS и Android).
Если же вы предпочитаете самостоятельное обучение, начните с OWASP MSTG и практики на Hack The Box — но будьте готовы, что путь займёт больше времени и потребует самодисциплины.