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

Список 10 основных уязвимостей приложений от OWASP Foundation — отличный ресурс для разработчиков, которые хотят создавать безопасные продукты. Дело в том, что многие мобильные приложения по своей природе уязвимы для угроз безопасности. Рассмотрим, например, ряд громких атак за последние годы. В их числе шпионское ПО Pegasus для WhatsApp, с помощью которого киберпреступники могли получить контроль над устройствами пользователей мессенджера. Другим примером был взлом приложения Pokémon Go, которое позволило пользователям реконструировать данные GPS и захватывать больше покемонов.

 

Исследования OWASP

Основываясь на опросах и анализе глобальной обратной связи, Проект безопасности мобильных приложений (OWASP) впервые предоставил информацию о связанных рисках в 2011 году. Впоследствии аналогичные исследования были проведены в 2014 и 2016 годах. Последнее из этих исследований является актуальнейшим на данное время.

В списках 2014 и 2016 годов полностью совпадает только один элемент, в остальном структура категорий сильно изменилась. Например, некоторые пункты были разделены, а некоторые, наоборот, объединены в один, что упростило их рассмотрение.

1. Неправильное использование платформы

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

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

• Ошибочное использование функции iOS Touch ID может привести к неавторизованному доступу к устройству.
• Неверное применение iOS Keychain, в следствии чего чувствительные данные, например ключи сессии или пароли, сохраняются в локальном хранилище приложения, а не в защищенном.
• Запрос чрезмерных или неверных разрешений платформы.
• Намерения (intents) в Android (используемые для запроса действия из другого компонента приложения), помеченные как открытые, могут раскрывать чувствительную информацию или разрешать неавторизованное выполнение.

Как предотвратить

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

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

2. Небезопасное хранилище данных

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

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

Как предотвратить

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

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

3. Небезопасная коммуникация

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

Мобильные приложения обычно взаимодействуют по типу клиент-сервер. В этом случае процесс перевода через сеть оператора или Интернет должен осуществляться безопасно. Трафик можно перехватить прокси-серверами, базовыми станциями, а также путем взлома Wi-Fi или установки вредоносного ПО на устройство.

Как предотвратить

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

• Установку SSL/TLS сертификатов от проверенных центров сертификации (CA).
• Предупреждение пользователей при обнаружении недействительного SSL/TLS сертификата или в случае провала проверки цепочки сертификатов.

4. Небезопасная аутентификация

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

Как предотвратить

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

Для предотвращения подобных рисков рекомендуется:

• Исключить локальную аутентификацию. Вместо этого можно передать ее выполнение на сторону сервера и скачивать данные приложения только после успешной проверки подлинности пользователя.
• Воздержаться от использования уязвимых методов аутентификации (например, удостоверения устройства), не хранить пароли локально, реализовать мультифакторную аутентификацию (MFA), запретить использование 4-циферного PIN-кода в качестве пароля и т.д.

5. Недостаточная криптографическая стойкость

Существует два случая, в которых криптография системы может быть скомпрометирована для раскрытия чувствительных данных:

1. Слабый внутренний алгоритм шифрования/дешифрования.
2. Пробелы в реализации самого процесса криптографии.

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

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

Как предотвратить

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

• Применять строгие стандарты криптографии, рекомендуемые Национальным институтом стандартов и технологий (NIST).
• Избегать хранения на устройствах важной информации.

6. Небезопасная авторизация

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

Как предотвратить

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

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

7. Качество кода клиента

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

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

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

Как предотвратить

Для устранения уязвимостей и прочих, вызванных некачественным кодом, проблем, рекомендуется:

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

8. Подделка кода

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

Как предотвратить

Подделка кода программы может вести к упущенным выгодам, краже личных данных, подрыву репутации и прочим пагубным последствиям. Для предотвращения подобных проблем существуют следующие рекомендации:

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

9. Реверс-инжиниринг

Злоумышленники могут дизассемблировать и декомпилировать приложение для анализа кода. Этот метод взлома особенно опасен, поскольку позволяет проверять, понимать и изменять код, чтобы включить вредоносные функции или показывать нежелательную рекламу. Поняв, как работает приложение, хакеры могут изменить его с помощью таких инструментов, как IDA Pro, Hopper и других. После реализации желаемого поведения они могут перекомпилировать приложение и использовать его в своих целях.

Как предотвратить

Помешать злоумышленнику выполнить реверс-инжиниринг программы может только невозможность произвести деобфускацию кода с помощью IDA Pro, Hopper и аналогичных инструментов.

10. Лишняя функциональность

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

Как предотвратить

Один из наиболее эффективных способов избежания подобных типов уязвимостей – это самостоятельный анализ безопасности кода. Таким образом вы сможете:

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

Заключение

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