По данным Statista в мире насчитывается около 3.5 млрд. пользователей смартфонов. Это значит, что жертвами небезопасных мобильных приложений могут стать очень многие.
Подготовленный фондом OWASP cписок 10 наиболее актуальных уязвимостей приложений – это отличный ресурс для разработчиков, стремящихся создавать защищенные продукты. Дело в том, что многие мобильные приложения по своей природе уязвимы для угроз безопасности. Вспомним, к примеру, ряд нашумевших атак, произошедших за последние годы. К ним можно отнести шпионское ПО Pegasus для WhatsApp, посредством которого злоумышленники смогли заполучить управление устройствами пользователей мессенджера. Еще одним примером явился взлом приложения Pokémon Go, который позволил пользователям с помощью реверс-инжиниринга манипулировать GPS-данными и ловить больше покемонов.
Многие другие приложения и организации, такие как Tinder и MediaTek, также стали жертвами атак. Но что же делает подобные ресурсы уязвимыми? Для мобильных приложений характерна более обширная поверхность атаки, чем для их веб-аналогов, так как они скачиваются с публичных площадок и дают возможность проинспектировать код. Плюсом к этому, такие приложения, как правило, собирают огромное количество пользовательской информации, что делает их еще более привлекательным средством для кибер-преступников.
Исследования OWASP
На основе проведенного опроса и анализа обратной связи мирового сообщества проект по обеспечению безопасности мобильных приложений (OWASP) впервые предоставил информацию о связанных с ней рисках в 2011 году. После этого аналогичные исследования проводились в 2014 и 2016 годах. Последнее из этих исследований и является наиболее актуальным на сегодня.
В списках 2014 и 2016 года полностью совпадает только один пункт, в остальном же структура категорий сильно изменилась. Например, некоторые пункты были разделены, а некоторые, наоборот, объединены в один, что упростило их рассмотрение.
Мы же с вами ознакомимся с версией списка уязвимостей 2016 года, попутно рассмотрев возможные способы их устранения.
1. Неправильное использование платформы
Данный вид уязвимостей стоит во главе списка. Независимо от того Android это или iOS, при разработке для любой из этих платформ необходимо придерживаться конкретных требований с целью обеспечения должного уровня безопасности итогового продукта. Но бывает, что при создании приложений некоторые из предписанных правил и рекомендаций непреднамеренно нарушаются или просто реализуются с ошибками.
В результате возникает угроза, вызванная неверным использованием какой-либо возможности платформы или отсутствием реализации протоколов безопасности. Здесь можно упомянуть следующие случаи:
- Ошибочное использование функции iOS Touch ID может привести к неавторизованному доступу к устройству.
- Неверное применение iOS Keychain, в следствии чего чувствительные данные, например ключи сессии или пароли, сохраняются в локальном хранилище приложения, а не в защищенном.
- Запрос чрезмерных или неверных разрешений платформы.
- Намерения (intents) в Android (используемые для запроса действия из другого компонента приложения), помеченные как открытые, могут раскрывать чувствительную информацию или разрешать неавторизованное выполнение.
Как предотвратить
Подобные уязвимости нужно устранять на серверной стороне. Наряду с соблюдением рекомендаций платформы по разработке, риски можно также минимизировать с помощью безопасных подходов к написанию кода и применения правильных настроек сервера. Помимо этого, уменьшить вероятность неверного использования платформы поможет:
- Запрет приложениям на взаимодействие друг с другом, ограничение доступа, реализация ограничительных прав доступа к файлам и др.
- Применение самого строгого класса защиты для цепочек ключей iOS и следование наилучшим методам разработки с целью избежания слабой реализации элементов управления.
2. Небезопасное хранилище данных
Мобильные устройства нередко теряются или крадутся, оказываясь в руках злоумышленников. Помимо этого, утечка личной информации пользователя может произойти из-за вредоносного ПО, которое позволяет атакующему задействовать уязвимости устройства. С помощью взлома или рутинга устройства можно легко обойти защиту шифрованием, поэтому разработчики ПО должны исходить из предположения, что злоумышленники могут получить доступ к файловой системе.
И поскольку практически все приложения так или иначе сохраняют информацию, очень важно реализовать ее сохранение в такой области, где она не будет доступна другому приложению или пользователю.
Как предотвратить
Производить тестирование приложения на уязвимость угрозам для выяснения, какие информационные активы обрабатываются, и как с этими данными взаимодействуют API. Это поможет:
- Определить, эффективно ли применяется шифрование, и как защищены ключи шифрования.
- Затруднить взлом кода с помощью обфускации, защиты против переполнения буфера и т.д.
- Избежать сохранения/кэширования данных там, где это возможно.
- Внедрить звуковые методы аутентификации и авторизации.
3. Небезопасная коммуникация
Если данные передаются незашифрованными в виде чистого текста, любой, кто отслеживает данную сеть, может перехватить и прочесть их.
Мобильные приложения, как правило, обмениваются данными по модели клиент-сервер. При этом процесс передачи через сеть оператора или интернет должен быть реализован безопасно. Траффик может перехватываться прокси-серверами, базовыми станциями, а также с помощью взлома WiFi или путем установки на устройство вредоносного ПО.
Как предотвратить
Для избежания кражи данных в процессе их передачи по сети следует полагаться на утвержденные индустрией протоколы шифрования и прочие практики, включая:
- Установку SSL/TLS сертификатов от проверенных центров сертификации (CA).
- Предупреждение пользователей при обнаружении недействительного SSL/TLS сертификата или в случае провала проверки цепочки сертификатов.
4. Небезопасная аутентификация
Прежде чем предоставить доступ, приложение должно проверить подлинность пользователя. Обход аутентификации обычно реализуется через существующие уязвимости, такие как неправильная проверка сервисных запросов сервером. Мобильные приложения должны проверять и удерживать подлинность пользователя, особенно в процессе передачи конфиденциальных данных, например, финансовой информации.
Как предотвратить
Использование слабых мест механизма аутентификации позволяет злоумышленникам обходить системы проверки паролей или получать дополнительные разрешения, осуществляя кражу данных и другие действия.
Для предотвращения подобных рисков рекомендуется:
- Исключить локальную аутентификацию. Вместо этого можно передать ее выполнение на сторону сервера и скачивать данные приложения только после успешной проверки подлинности пользователя.
- Воздержаться от использования уязвимых методов аутентификации (например, удостоверения устройства), не хранить пароли локально, реализовать мультифакторную аутентификацию (MFA), запретить использование 4-циферного PIN-кода в качестве пароля и т.д.
5. Недостаточная криптографическая стойкость
Существует два случая, в которых криптография системы может быть скомпрометирована для раскрытия чувствительных данных:
- Слабый внутренний алгоритм шифрования/дешифрования.
- Пробелы в реализации самого процесса криптографии.
Успешный взлом в таких случаях может быть следствием ряда факторов, включая:
- Обход встроенных алгоритмов шифрования кода.
- Неправильное управление цифровыми ключами.
- Использование пользовательских или устаревших протоколов шифрования.
Как предотвратить
Недостатки системы криптографического управления доступом могут вести к утечке чувствительных данных с устройства. В связи с этим следует:
- Применять строгие стандарты криптографии, рекомендуемые Национальным институтом стандартов и технологий (NIST).
- Избегать хранения на устройствах важной информации.
6. Небезопасная авторизация
Для разных пользователей предусматриваются разные права, в результате чего одни получают стандартный доступ, в то время как другие, например администраторы, могут иметь дополнительные разрешения и привилегии. Слабые схемы авторизации, несмотря на успешную проверку подлинности пользователя, могут не справляться с проверкой его прав на доступ к запрашиваемым ресурсам. Подобный недочет позволяет хакерам авторизовываться и выполнять атаки с целью повышения привилегий.
Как предотвратить
Как и в случае с аутентификацией, недочеты авторизации могут вести к краже данных, подрыву репутации и даже штрафам за несоблюдение требований. В качестве противодействия этим рискам стоит рассмотреть следующие варианты:
- Реализовать проверку сервером каждого запроса на предмет соответствия входящих идентификаторов той личности пользователя, с которой они ассоциируются.
- Проверять роли и разрешения аутентифицированного пользователя, используя информацию из бэкенд-систем, а не из мобильного устройства.
7. Качество кода клиента
Эта категория в некотором смысле является общей причиной проблем мобильного клиента, связанных с неправильной реализацией кода.
Атакующий может передавать особые входные данные в вызовы функций, провоцируя их выполнение и наблюдая за поведением приложения. В связи с этим падает производительность, повышается потребление памяти и т.п. В этом случае стоит иметь в виду, что ошибки в коде нужно исправлять локальным способом, поскольку они возникают в мобильном клиенте и отличаются от ошибок серверной стороны. Привести же они могут к:
- уязвимостям форматирующих строк;
- переполнению буфера;
- внедрению небезопасных сторонних библиотек;
- удаленному выполнению кода.
При разработке приложений зачастую используются сторонние библиотеки, которые сами по себе могут содержать баги и быть недостаточно протестированы. Эти нюансы находятся вне контроля разработчика, поскольку исходный код ему недоступен. В остальных же случаях чаще всего ошибки кода исправляются переписыванием его соответствующих частей. Но что еще можно сделать?
Как предотвратить
Для устранения уязвимостей и прочих, вызванных некачественным кодом, проблем, рекомендуется:
- Использовать автоматизированные инструменты для тестирования буфера на переполнение, определения утечек памяти и др.
- Опираться на ревью исходного кода и изначально создавать его в понятном, хорошо документированном виде.
- Применять в организации согласованные шаблоны написания кода.
8. Подделка кода
Иногда в магазинах встречаются поддельные версии приложений. От оригинала их отличает встроенное в исполняемый файл вредоносное содержимое, например закладка, позволяющая получать несанкционированный доступ к системе. Злоумышленники могут повторно подписывать эти поддельные приложения и размещать их в сторонних магазинах или даже напрямую доставлять жертве через фишинговые атаки.
Как предотвратить
Подделка кода программы может вести к упущенным выгодам, краже личных данных, подрыву репутации и прочим пагубным последствиям. Для предотвращения подобных проблем существуют следующие рекомендации:
- Приложение должно уметь идентифицировать любое нарушение целостности кода (т.е. изменение или внедрение посторонних элементов) и соответствующим образом реагировать на это в среде выполнения. Сообщить же пользователям о легитимных изменениях кода можно, например, посредством сертификатов его подписи.
- Внедрить техники, препятствующие выполнению поддельных приложений, например, контрольные суммы, цифровые подписи, усиление кода и прочие методы проверки.
9. Реверс-инжиниринг
Злоумышленники могут разобрать и декомпилировать приложение для анализа кода. Этот способ взлома особенно опасен, так как позволяет инспектировать, понять и изменить код, включив в него вредоносную функциональность или транслирование нежелательной рекламы. Разобравшись в принципе работы приложения, хакеры могут изменить его с помощью таких инструментов, как IDA Pro, Hopper и прочих. После реализации нужного им поведения, они могут повторно скомпилировать приложение и использовать в своих умыслах.
Как предотвратить
Помешать злоумышленнику выполнить реверс-инжиниринг программы может только невозможность произвести деобфускацию кода с помощью IDA Pro, Hopper и аналогичных инструментов.
10. Лишняя функциональность
Иногда разработчики могут ненамеренно оставлять закладки или дополнительную функциональность, которые не очевидны для конечного пользователя. В результате продукт выпускаются в продакшен с функцией, которая не должна быть доступной, что создает дополнительные риски для безопасности приложения.
Хакеры эксплуатируют подобные слабые места программ непосредственно из своих систем, не нуждаясь в содействии со стороны регулярных пользователей. Они изучают файлы конфигурации, двоичные файлы и прочие компоненты, раскрывая функционал бэкенд-части, который затем используют для совершения атак.
Как предотвратить
Один из наиболее эффективных способов избежания подобных типов уязвимостей – это самостоятельный анализ безопасности кода. Таким образом вы сможете:
- Проверить настройки приложения на предмет наличия скрытых переключателей.
- Убедиться, что логи не содержат чрезмерно описательных инструкций о работе сервера.
Обобщение
Приведенный список уязвимостей мобильных приложений может послужить отправной точкой для организаций, разработчиков, специалистов по безопасности и пользователей, которые только начинают решать соответствующие проблемы. Здесь были приведены краткие определения для каждого вида уязвимости, примеры сценариев атаки, способы их предотвращения и рекомендованные стратегии по минимизации ущерба.
Но имейте в виду, что этот список представляет лишь необходимый минимум. Поэтому с целью реализации максимально эффективного и безопасного продукта советуем изучить данную тему более углубленно.
