Опубликовано

Как самостоятельно проверить безопасность

безопасность приложения

Где-то в параллельной вселенной все понимают, что никто не проверит приложение на безопасность кода лучше самих разработчиков. Но что делать, если нет ни опыта, ни времени?

Ответ — читать инструкцию и действовать.

Реально ли справиться самим?

Анализ защищенности дает уверенность, что вас невозможно взломать.

Ранее мы рассказывали о важности безопасности: https://blog.upmob.ru/2021/05/12/%d0%b0-%d1%87%d1%82%d0%be-%d0%bf%d0%be-%d0%b1%d0%b5%d0%b7%d0%be%d0%bf%d0%b0%d1%81%d0%bd%d0%be%d1%81%d1%82%d0%b8/

Но что проверить? Какие инструменты использовать?Разбираемся сегодня.

 

Ненужная информация

На старте необходимо удостовериться:  не осталось ли в релизной сборке отладочной информации и журналов работы приложения.

Что проверить: адреса тестовых стендов и других компонентов, API-ключи тестовых сервисов (к примеру, аналитики) или сообщения, используемые при отладке приложения. С отладочной информацией злоумышленнику проще понять логику работы приложения. Кроме того, изучив тестовый стенд и поняв, какие сервисы есть за фронтом на продакшн, какие базы данных используются на стороне сервера — атакующий легко получит сведения для построения векторов атаки.

Что делать?

Убрать лишнюю информацию. Вам в помощь фреймворк MobSF. Загрузите в него релизную сборку  приложения и далее:

для iOS: проверить все строки, определенные в ipa-образе, в разделе Scan Options / View Strings.

для Android: просмотреть строки в разделе Reconnaissance / Strings. И обратить внимание на раздел Security Analysis / Code Analysis.

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

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

Что делать?

Используйте Console.app для iOS и adb для Android, чтобы понять: включено ли логирование в релизной сборке приложения и что туда попадает.

Для того, чтобы логи не уходили в релизную сборку— грамотно спроектируйте класс Logger. Если есть необходимость экстренного исправления — настройте в скриптах релизной сборки удаление методов логирования из кода. Это можно сделать: для iOS через препроцессорный макрос, для Android — с помощью применения правил ProGuard.

Проверка ограничения на отправку СМС

Поиск уязвимости к SMS Abuse актуален для приложений, в которых есть действия, связанные с СМС: двухфакторная аутентификация, восстановление пароля или перевод денежных средств.

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

Что делать?

Вспомнинаем все эндпоинты, где операции требуют отправки СМС. Пробуем отправить сразу по 20 запросов к каждому с одного IP-адреса (или от одного пользователя). Если сообщения приходят — система подвержена этой атаке.

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

Ревизия библиотек

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

Что делать?

При помощи MobSF смотрим: какие библиотеки собраны неправильно и чего не хватает. В помощь раздел Security Analysis / Binary Analysis.

Компоненты для работы с внешними ссылками

Внешние ссылки (App Links, Deep Links, Universal Links) могли быть нужны по разным причинам:

для обработки возвращаемых значений при OAuth-авторизации

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

для возможности аналитики.

Помните: при встраивании компонентов для работы с внешними ссылками по отношению к другим приложениям эти компоненты всегда открыты. Соответственно, злоумышленник в состоянии отправлять им на обработку вредоносное содержимое.

Что делать?

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

При встраивании компонентов для работы с App Links отдельно удостоверьтесь, что сервер сконфигурирован для проверки подписи вашего приложения. В противном случае ссылку можно перехватить.

Если приложение обрабатывает и Deep Links, и App Links, определите для них разные компоненты. В противном случае нивелируются собственные меры безопасности, которые есть у App Links.

Другие открытые компоненты

В Android-клиентах специально определяют открытые компоненты — activity, сервисы и другие, которые  обрабатывают запросы от других приложений, установленных на том же устройстве.

Для атакующего каждый открытый компонент — дополнительная возможность.

Что делать?

Определите: какие компоненты действительно необходимы для работы с другими приложениями и компонентами ОС. Увидеть их все в одном окне можно с помощью MobSF (раздел Security Analysis / Manifest Analysis).

Работа с компонентом WebView

Актуально для приложений, которые задействуют WebView:

отображают с его помощью документы (условия использования приложения, документы о согласии обработки персональных данных и т.д.)
проводят авторизацию через сторонний сайт ( Google, Apple, Яндекс)
целиком (или отдельный модуль) написан на фреймворках наподобие React Native.
WebView требует отдельных мер безопасности.

Что делать?

Для показа PDF-файлов или HTML можно воспользоваться штатными возможностями системы: на iOS — UIDocumentInteractionController, на Android — ACTION_VIEW. Максимально просто, удобно и безопасно.

Если необходимо продемонстрировать отчет, который наполняется динамически — уже нужен WebView. И тут лучше  убедиться, что при создании этого компонента отключено исполнение JavaScript-кода. Злоумышленник не в состоянии оказать влияние на эти данные. Но отключить поддержку JavaScript-кода лучше из принципа минимальных привилегий.

Для сложных задач можно использовать:

для iOS — WKWebView-компонент. Также SFSafariViewController, но он менее универсален (нельзя отключить обработку JavaScript-кода при необходимости)
для Android — Chrome Custom Tabs вместо WebView. Если используете WebView, включайте поддержку нескольких окон для защиты пользователей на старых версиях ОС от недавно найденной уязвимости CVE-2020-6506.

Данные в резервных копиях телефона

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

Что делать?

Проверьте: какую информацию приложение хранит в резервной копии. На iOS проще можно применить  обычный Finder (или iTunes), на Android — adb. Узнать содержимое резервной копии можно с помощью iMazing и Android Backup Extractor.

SSL Pinning

Без SSL Pinning (механизм привязки сертификата сервера), приложение использует политику проверки сертификата сервера по умолчанию. Это чревато тем, что подмена точки доступа и немного социальной инженерии ведет к уязвимости атаки типа «человек посередине» (MitM). Таким образом  злоумышленник может читать и даже вносить изменения в сообщения, которые передаются между приложением и сервером.

Для того, чтобы встроить механизм, не ограничивайтесь HTTP-соединениями. SSL Pinning настраивается  для любого протокола, обернутого в TLS: веб-сокетов, XMPP и т.д.

Что делать?

Чтобы понять, настроен ли у вас SSL Pinning потребуются — Fiddler, Charles и подобные программы для отладки HTTP- и HTTPS-трафика.

На iOS можно настроить перенаправление трафика с телефона на HTTP-прокси и установить на устройство сертификат для HTTP-прокси. Если трафик приложения будет зарегистрирован на стороне HTTP-прокси, значит, у вашего клиента SSL Pinning не настроен или настроен неправильно.
На Android необходимо предварительно добавить в манифест network-security-config с настройкой доверия пользовательским сертификатам. После выполнить ту же проверку, что и для iOS.

 

В заключении:

Пентест важен. Но все же лучше брать в расчет безопасность с самого начала разработки.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *