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

Наша команда разрабатывает бизнес-приложение – защищенный корпоративный коммуникатор. Перед запуском в продакт встал вполне резонный вопрос: действительно ли наш продукт соответствует всем требованиям по кибербезопасности?

Как определить, безопасно ли приложение

Есть несколько способов проверки защищенности приложения:

• Внутренний аудит – самим провести пентест или анализ защищенности приложения.
• Внешний аудит – подключить к проверке специалистов по кибербезопасности.

Оба метода опираются на одни и те же требования – стандарты безопасности OWASP – независимой международной некоммерческой организации. И хотя никаких сертификатов проект не выдает, именно рейтинг OWASP является стандартом оценки уровня кибербезопасности во всем мире.

Рейтинг уязвимостей по OWASP обновляется каждые три-четыре года. В 2021 году топ рисков выглядел так, посмотрите, что изменилось по сравнению с 2017 годом:

Для собственных пентестов компании часто создают чек-листы именно по этому рейтингу и добавляют в него специфичные требования в зависимости от отрасли или условий. Внешние специалисты по кибербезопасности также берут за основу топ OWASP.

Какие кибер-угрозы можно обнаружить и как их исправить

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

Тестирование проходила в2с-версия приложения для Android и iOS, а также API – она вышла раньше корпоративной, чтобы в полевых условиях проверить особенности работы ПО на разных смартфонах, нагрузку, географическую распространенность и т.д. На момент проведения аудита у нас уже было более 25 тыс. пользователей по всему миру. Все работы проводились методом «черного ящика». То есть, у экспертов по кибербезопасности имелись на руках только спецификации системы, но не было доступа к коду приложения.

Что показал анализ безопасности

В результате аудита было выявлено:

• В приложении на платформе Android – 12 уязвимостей: 2 высокого, 3 среднего и 7 низкого уровня риска.
• В приложении на платформе iOS – 12 уязвимостей: 1 высокого, 6 среднего и 5 низкого уровня риска.
• В API, используемом мобильным приложением, 2 уязвимости низкого уровня риска.

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

Уязвимости в приложении: причины, риски, как устранить

Классификатор OWASP – что-то вроде сферического коня в вакууме. Идеальная концепция, оторванная от реальной жизни. Оценка приложения по этому чек-листу позволяет создать совершенное с точки зрения безопасности приложение. Но, как говорится, идеальный пациент – мертвый пациент.

Проверяя приложение по OWASP, готовьтесь к тому, что уязвимости из чек-листа в контексте архитектуры и бизнес-логики приложения не будут считаться уязвимостями. Например, у вас приложение для доставки еды, а OWASP скажет, что оно небезопасное из-за наличия pin-кода в 4 символа. Хотя, с точки зрения здравого смысла, кому понадобится охранять список любимых сыров восьмизначным паролем?

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

Критические уязвимости – высокая степень риска

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

Прочие уязвимости: причины и решения

Еще один важный момент – многие риски в классификаторе OWASP связаны с утратой физического доступа к устройству. Фактические варианты реализации этих угроз:

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

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

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

1. Некорректная реализация механизма SSL-pinning (низкий уровень)

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

Теоретически в процессе установки SSL-соединения по протоколу HTTPS можно подменить сертификат. Клиент будет думать, что общается с правильным узлом, а на самом деле зашифрованный трафик перехватывается злоумышленником. При реализации SSL-pinning защищенное соединение осуществляется только с сертификатом, который вшит в клиента.

SSL-pinning – сложный механизм, нужен для того, чтобы защитить сверхчувствительные данные, например, в онлайн-банках. Защищать таким образом открытые данные – избыточная мера. А в логике нашего приложения даже вдвойне избыточная, так как вся информация, пересылаемая через него, уже защищена ассиметричным шифрованием. Получается масло масляное, потому что SSL шифрует TLS-алгоритмом шифрования и без того зашифрованные данные.

Несмотря на то, что отсутствие SSL-pinning для нашего приложения и пользователей не несет вообще никаких глобальных рисков, эту уязвимость мы устранили. Но были и те, которые пришлось отнести к категории «неустранимых» угроз.

2. Раскрытие пользовательских данных в оперативной памяти

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

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

3. Использование устаревших программных компонентов

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

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

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

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

Результат устранения уязвимостей

Из 12 уязвимостей, выявленных в результате аудита:

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

Как у других обстоят дела с кибербезопасностью

Пробелы в безопасности есть абсолютно у всех приложений. В этом можно убедиться, если заглянуть в итоги аудита Group IB, в котором эксперты по кибербезопасности сравнивают уровень защищенности трех основных мессенджеров – Telegram, Signal и Wickr Me. У двух из трех исследуемых мессенджеров была найдена та же «неустранимая» неуязвимость, что и у нашего приложения – небезопасное хранение чувствительных данных в локальном хранилище, которые становятся доступны root-пользователю.

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

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

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

1. Повышайте собственную экспертизу. Внешний аудит – это хорошо, но, как показала практика, сторонняя оценка не всегда может быть релевантна вашему проекту. Обучайте разработчиков и повышайте их квалификацию. Обязательно формируйте внутренние чек-листы и стандарты перед каждым релизом.
2. Мониторьте ситуацию постоянно. Внедряете функцию – сразу проверяйте по чек-листу, соответствует ли требованиям, нет ли утечки памяти. Минимум раз в три месяца – проверка обновлений операционной системы и библиотек. В идеале – процесс должен быть постоянным, с проверкой каждого релиза.
3. Не пренебрегайте внешней оценкой. Не стоит считать, что требования OWASP не соотносятся с реальностью и можно обойтись своими силами. Важно смотреть на продукт не только «изнутри», с точки зрения бизнес-логики, но и с позиции независимой оценки. Комплексный аудит прекрасно в этом поможет и укажет на те недостатки, которые вы могли и не заметить.
4. Приготовьтесь инвестировать. Развитие внутренних компетенций, хантинг специалистов по безопасности, пентесты и анализы – на это стоит закладывать не меньше 30% сверх бюджета. Безопасность действительно стоит очень дорого, мы убедились в этом на собственном опыте. Учитывайте это при работе с продуктом, ведь взлом может стоить гораздо дороже.

Также читайте: