OWASP Mobile Top 10: разбираем угрозы для iOS и Android

Мобильное приложение сегодня – это точка доступа к данным пользователя, платежам и бизнес-логике. Любая уязвимость в этой точке напрямую превращается в риск: утечка данных, взлом аккаунтов, финансовые потери. OWASP TOP 10 – что это такое?

OWASP Mobile Top 10 – это практический стандарт, который показывает, где именно мобильные приложения чаще всего ломаются с точки зрения безопасности.

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

Если приложение работает с авторизацией, персональными данными или платежами – игнорировать эти угрозы уже нельзя.

OWASP Mobile Top 10 – это список наиболее критичных уязвимостей мобильных приложений для iOS и Android, сформированный на основе реальных атак и практики безопасности. Особенно важно для: 

• продуктовым компаниям с мобильными приложениям;
• финтех и e-commerce проектам;
• стартапам с авторизацией и пользовательскими данными;
• командам, которые планируют масштабирование продукта.

Его используют для аудита приложения и проверки на безопасности перед релизом. Если приложение хранит или обрабатывает данные пользователя – OWASP TOP 10 это базовый уровень безопасности, даже если приложение собрано через конструктор (подробнее в обзоре конструкторов мобильных приложений).

OWASP 10 отличается от веб-версии тем, что фокусируется на рисках клиентской среды – устройства пользователя, а не только серверной части. В мобильных приложениях зона доверия смещается: часть логики, данных и взаимодействий выходит за пределы контролируемой инфраструктуры.

Ключевое отличие – доступ к клиенту. Мобильное приложение можно декомпилировать и анализировать, поэтому любая логика на стороне клиента потенциально уязвима.

Вторая разница – локальное хранение данных. Токены и пользовательская информация могут сохраняться на устройстве и извлекаться без должной защиты.

Третья – неконтролируемая среда выполнения. Root/jailbreak, эмуляторы и модифицированные устройства позволяют вмешиваться в работу приложения.

Четвертая – перехват трафика. Без дополнительной защиты запросы можно анализировать и подменять.

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

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

M1: Ненадлежащее использование платформы (Improper Platform Usage)

Это ошибки в использовании встроенных механизмов безопасности iOS и Android. Проявляется, когда:

• неправильно настроены permissions;
• игнорируются secure API платформы;
• используется небезопасная работа с WebView.

Риск – обход системной защиты устройства и доступ к чувствительным данным.

M2: Небезопасное хранение данных (Insecure Data Storage)

Данные сохраняются на устройстве без защиты или шифрования. Типичные случаи:

• токены в plain text;
• данные в SQLite без шифрования;
• кеш с персональной информацией.

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

M3: Небезопасная передача данных (Insecure Communication)

Данные передаются между приложением и сервером без достаточной защиты.

Проявляется через:

• отсутствие HTTPS;
• отсутствие certificate pinning;
• уязвимость к MITM-атакам.

Риск – перехват и изменение данных в процессе передачи.

M4: Небезопасная аутентификация (Insecure Authentication)

Ошибки в логике входа и проверки пользователя.

Типичные проблемы:

• слабая проверка токенов;
• отсутствие защиты от brute force;
• неправильная работа с сессиями.

Таким образов возможен несанкционированный доступ к аккаунтам.

M5: Недостаточная криптография (Insufficient Cryptography)

Использование слабых или устаревших методов шифрования.

Проявляется, когда:

• используются небезопасные алгоритмы;
• неправильно реализовано шифрование;
• ключи хранятся в коде.

Остается возможность расшифровки данных и компрометация безопасности.

M6: Небезопасная авторизация (Insecure Authorization)

Отсутствие или неправильная проверка прав доступа.

Типичные сценарии:

• пользователь получает доступ к чужим данным;
• backend не проверяет права;
• логика доступа реализована на клиенте.

Риск – утечка данных и нарушение бизнес-логики.

M7: Качество клиентского кода (Client Code Quality)

Ошибки в коде приложения, которые приводят к уязвимостям.

Проявляется через:

• небезопасные библиотеки;
• отсутствие обработки ошибок;
• уязвимости в логике.

Возможна эксплуатация багов для обхода защиты или доступа к данным.

M8: Подделка кода (Code Tampering)

Изменение кода приложения после установки.

Типичные сценарии:

• модификация APK/IPA;
• внедрение вредоносного кода;
• обход встроенной логики.

Риск – изменение поведения приложения и обход ограничений.

M9: Обратная разработка (Reverse Engineering)

Анализ приложения с целью извлечения логики и данных.

Проявляется, когда:

• код не защищен;
• отсутствует обфускация;
• чувствительные данные находятся в коде.

Есть возможность раскрытия API, ключей, бизнес-логики.

M10: Лишняя функциональность (Extraneous Functionality)

В приложении остается функциональность, не предназначенная для пользователя.

Типичные случаи:

• тестовые endpoints;
• debug-инструменты;
• скрытые функции.

Возможно использование этих функций для атаки или обхода защиты.

Угрозы отличаются точкой атаки. На Android чаще атакуют среду и само приложение, на iOS – логику и API.

Android более открыт: возможен sideloading, root-доступ и модификация APK, что важно учитывать при разработке приложений на Android.. Это позволяет изменять поведение приложения, обходить проверки и извлекать данные.

iOS ограничивает установку и изолирует приложения, поэтому прямое вмешательство сложнее, что снижает риски при разработке приложений для iPhone. Основные риски – ошибки в авторизации, хранении данных и проверке доступа на сервере.

Например на Android можно модифицировать приложение и отключить клиентские проверки. На iOS – получить доступ к чужим данным, если backend некорректно проверяет права.

Уязвимости OWASP Mobile Top 10 закрываются не точечно, а через архитектуру, где клиенту не доверяют, что напрямую зависит от выбранного стека (детально технологии разработки iOS-приложений), а критическая логика и проверки вынесены на сервер.

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

Затем важно защитить данные и передачу. Использовать только HTTPS, внедрять certificate pinning, хранить токены в защищенных хранилищах (Keychain / Secure Storage), не кешировать критические данные.

Контролировать среду и целостность приложения. Проверять root/jailbreak, внедрять защиту от модификации и обфускацию кода, исключать debug-функции из продакшена.

Обязательно корректно реализовать аутентификацию и авторизацию. Использовать короткоживущие токены, обновление через refresh, проверку прав на сервере, защиту от brute force.

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

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

1. Статический анализ (SAST). Проверяется код и сборка приложения: хранение данных, использование криптографии, наличие ключей и небезопасных библиотек.
2. Динамический анализ (DAST). Приложение тестируется в работе: перехват трафика, проверка HTTPS, попытки MITM-атак, анализ запросов к API.
3. Тестирование среды. Запуск на root/jailbreak устройствах и эмуляторах, проверка устойчивости к модификации и вмешательству.
4. Проверка логики и доступа. Тестируются сценарии авторизации и авторизации: можно ли получить доступ к чужим данным, обойти ограничения или изменить поведение приложения.
5. Пентест. Имитация реальной атаки с попыткой извлечь данные, обойти защиту и найти слабые точки.

OWASP ТОП 10 используется как чек лист – каждая категория проверяется отдельно через код, поведение приложения и взаимодействие с сервером.

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

Практический подход простой: каждая категория OWASP должна быть пройдена обязательная проверка – на уровне архитектуры, разработки и тестирования.

Главное – не откладывать безопасность на финальный этап. Чем раньше она встроена в продукт, тем дешевле и эффективнее ее реализовать.

OWASP top 10 – это базовый стандарт, который стоит использовать как обязательный чек-лист перед релизом. Пройдите его для своего приложения – и вы закроете большинство критических уязвимостей еще до того, как они превратятся в проблему.