Понимание 10 главных рисков OWASP Mobile на реальных примерах

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

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

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

Наряду с прочим, они также составили список OWASP Mobile Top 10 угроз безопасности в мобильных приложениях.

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

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

Прежде чем рассматривать риски, давайте посмотрим на статистику.

NowSecure изучил приложения в магазине Google Play, и магазин приложений обнаружил, что более 85% приложений нарушают один из рисков.

Из этих приложений 50% имели небезопасное хранилище данных, и где-то такое же количество приложений работало с риском небезопасного обмена данными . Вот график, показывающий процент возникновения 10 основных рисков OWASP Mobile

Список 10 наиболее распространенных угроз для мобильных приложений и рекомендации по их предотвращению

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

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

Реальный случай:

Три приложения для iOS : «Приложение Fitness Balance», «Мониторинг сердечного ритма» и «Приложение для отслеживания калорий» стали известны из-за обхода Apple Touch ID. Они просили пользователей использовать отпечаток пальца для получения информации о фитнесе, в то время как они использовали его для взимания денег с App Store.

Рекомендации, которых следует избегать:

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

M2: Небезопасное хранение данных

OWASP считает угрозой, когда кто-то получает доступ к потерянному/украденному мобильному устройству или когда вредоносное ПО или другое переупакованное приложение начинает действовать от имени злоумышленника и выполняет действия на мобильном устройстве.

Уязвимость небезопасного хранилища данных обычно приводит к следующим рискам:

• Мошенничество
• Кража личных данных
• Материальная потеря.
• Ущерб репутации
• Нарушение внешней политики (PCI)

Реальный случай :

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

Рекомендации, которых следует избегать:

• Для iOS методы обеспечения безопасности OWASP рекомендуют использовать специально созданные уязвимые приложения, такие как iGoat, для моделирования угроз их среды разработки и приложений. Это поможет разработчикам приложений для iOS понять, как API взаимодействуют с процессами приложений и информационными активами.
• Разработчики приложений для Android могут использовать оболочку Android Debug Bridge для проверки прав доступа к файлам целевого приложения и СУБД для проверки шифрования базы данных. Им также следует использовать инструмент анализа памяти и монитор устройств Android, чтобы убедиться, что в памяти устройства нет непреднамеренных данных.

M3: Небезопасное общение

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

• Злоумышленник, который разделяет вашу локальную сеть — скомпрометированный Wi-Fi
• Сетевые или операторские устройства — вышки сотовой связи, прокси-серверы, маршрутизаторы и т. д.
• Вредоносное ПО на мобильном устройстве.

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

• Кража личных данных
• Мошенничество
• Репутационный ущерб.

Реальный случай:

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

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

«Вы можете определить, где находится телефон или ребенок, вы можете получить доступ к аудио или звонить детям по телефону», — сказал Дерал Хейланд, руководитель исследования IoT в Rapid7.

Рекомендации, которых следует избегать:

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

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

• Используйте сертификаты, предоставленные доверенными проверками цепочки SSL.
• Не отправляйте конфиденциальные данные по альтернативным каналам, таким как MMS, SMS или push-уведомления.
• Примените отдельный уровень шифрования к конфиденциальным данным, прежде чем передавать их в канал SSL.

M4: небезопасная аутентификация

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

Влияние M4 на бизнес может быть следующим:

• Кража информации
• Репутационный ущерб
• Несанкционированный доступ к данным.

Реальный случай :

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

Злоумышленник вошел в систему с помощью украденных учетных данных жертвы, и, дойдя до страницы, где нужно было ввести PIN-код или ответ безопасности, злоумышленник использовал измененную строку в веб-URL, которая установила компьютер как распознанный. Это позволило ему пересечь сцену и инициировать банковские переводы.

Рекомендации, которых следует избегать:

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

M5: Недостаточные криптографические риски

Агенты угроз в этом случае — это те, кто имеет физический доступ к данным, которые были зашифрованы неправильно. Или когда вредоносное ПО действует от имени противника.

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

• Кража информации
• Кража интеллектуальной собственности
• Кража кода
• Нарушения конфиденциальности
• Репутационный ущерб.

Реальный случай :

Некоторое время назад группа реагирования на чрезвычайные ситуации в киберпространстве DHS Industrial Control Systems и рекомендации Philips предупреждали пользователей о возможной уязвимости в приложении Philips HealthSuite Health для Android .

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

Рекомендации, которых следует избегать:

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

M6: Небезопасные риски авторизации

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

Это может привести к следующим проблемам:

• Кража информации
• Репутационный ущерб
• Мошенничество

Реальный случай :

Специалисты по информационной безопасности Pen Test Partners взломали умную автомобильную сигнализацию Pandora . Теоретически приложение используется для отслеживания автомобиля, отключения двигателя в случае его угона и блокировки до прибытия полиции.

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

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

Рекомендации, которых следует избегать:

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

M7: Риски низкого качества кода

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

Реальный случай :

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

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

Рекомендации, которых следует избегать:

• Согласно практике безопасного кодирования OWASP , код следует переписывать на мобильном устройстве, а не исправлять его на стороне сервера. Разработчики должны учитывать, что плохой код на стороне сервера сильно отличается от плохого кода на клиентском уровне. Это означает, что как слабым элементам управления на стороне сервера , так и элементам управления на стороне клиента следует уделять отдельное внимание.
• Разработчик должен использовать сторонние инструменты статического анализа для выявления переполнения буфера и утечек памяти.
• Команда должна создать список сторонних библиотек и периодически проверять его на наличие новых версий.
• Разработчики должны рассматривать все входные данные клиента как ненадежные и проверять их независимо от того, исходят ли они от пользователей или приложения.

M8: Риски подделки кода

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

Рекомендации, которых следует избегать:

• Разработчики должны убедиться, что приложение способно обнаруживать изменения кода во время выполнения.
• Файл build.prop необходимо проверить на наличие неофициального ПЗУ в Android и выяснить, рутировано ли устройство.
• Разработчик должен использовать контрольные суммы и оценивать цифровые подписи, чтобы определить, не произошло ли изменение файла.
• Кодировщик может убедиться, что ключи, код и данные приложения будут удалены после обнаружения взлома.

M9: Риск обратного проектирования

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

Реальный случай :

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

Рекомендации, которых следует избегать:

• Согласно OWASP Mobile Security , лучший способ защитить приложение от риска — использовать те же инструменты, которые хакеры использовали бы для реверс-инжиниринга.
• Разработчик также должен запутать исходный код, чтобы его было трудно читать, а затем выполнить обратный инжиниринг.

M10: Риск посторонней функциональности

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

Реальный случай :

Идея приложения Wifi File Transfer заключалась в том, чтобы открыть порт на Android и разрешить подключения с компьютера. Проблема ? Отсутствие аутентификации, такой как пароли, то есть любой мог подключиться к устройству и получить к нему полный доступ.

Рекомендации, которых следует избегать:

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