1
Пример уязвимости — «Передача чувствительных данных в открытом виде» 
Чувствительные данные пользователя, как ФИО, номер телефона, пароли, при взаимодействии с сервером передаются в открытом виде. С помощью атаки MITM (перехвата данных) злоумышленник может получить и использовать эти данные в своих целях. 
Возможные риски
  1. Персональные данные, включая пароли, данные личных карт могут попасть не в те руки и использоваться в корыстных целях: компрометация, шантаж, использование денежных средств и т.д.
  2. Трафик может быть модифицирован, и все данные будут прочитаны, изменены или вовсе удалены.
  3. Компания может понести серьезные финансовые потери и репутационные риски.
2
Пример уязвимости — «Отсутствует ограничение на вызов метода отправки СМС» 
Отправка SMS-сообщений при авторизации на разные номера не имеет ограничений по времени. То есть на экране авторизации вводим номер телефона, возвращаемся назад и вводим другой номер телефона, при этом действие можно повторять неограниченное количество раз.
Возможные риски
  1. Автоматическая DDoS-атака приведет к отказу в обслуживании и серьезным финансовым потерям. 
  2. Могут исчерпаться лимиты, предназначенные для SMS-рассылки.
Когда нужно проводить аудит?

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

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

 

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

 

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

Мы анализируем:

  • Где и как сохраняются чувствительные данные
  • В каком виде хранятся данные: в зашифрованном или открытом
  • Какой используется тип криптографии
  • Каким образом злоумышленник может извлечь данные
Наши инструменты

Для оценки защищенности приложения мы используем рейтинг уязвимостей мобильного приложения OWASP Mobile TOP 10 и методики проверки OWASP MASVS, OWASP MSTG, признанные во всем мире.

 

 

OWASP Top 10 Mobile — это регулярно обновляемый рейтинг основных угроз безопасности. Международные эксперты по информационной безопасности OWASP рекомендуют всем компаниям учитывать выводы документа при разработке ПО, чтобы минимизировать риски атаки.

Согласно рейтингу, самые опасные уязвимости мобильных приложений:

  1. Обход архитектурных ограничений
  2. Небезопасное хранение данных
  3. Небезопасная передача данных
  4. Небезопасная аутентификация
  5. Слабая криптостойкость
  6. Небезопасная авторизация
  7. Контроль содержимого клиентских приложений
  8. Модификация данных
  9. Анализ исходного кода
  10. Скрытый функционал
Мы проводим анализ защищенности с использованием фреймворка MobSF, ADB, платформы Burp suit, инструментов Frida, Objection и Charles Proxy в привязке к используемым технологиям и функциональности приложения.
Этапы аудита
Мы проводим аудит по разработанному чек-листу.
01
Проверяем, что приложение защищено в этих аспектах:
  • Безопасное хранение данных​​
  • Механизмы аутентификации
  • Безопасная передача данных
  • Конфигурация сборки
  • Устойчивость к реверс-инжинирингу
  • Бизнес-логика приложения
02
Оцениваем уровень опасности найденных уязвимостей по методике CVSS 3.1.
03
Описываем уязвимые компоненты, примеры эксплуатаций найденных уязвимостей
04
Подготавливаем рекомендации
Результат
По итогам аудита мы формируем отчет с подробным описанием уязвимостей и уровня их опасности, возможных рисков и даем рекомендации по их устранению.
  • Аудит позволяет приоритезировать рекомендации по степени критичности уязвимостей и исправить все ошибки, пока они не принесли бизнесу серьезные потери.

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

Шкала оценки критичности безопасности. Численной оценке от нуля до десяти соответствуют категории. None, Low, Medium, High, Critical.

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