Книга: Мобильное приложение как инструмент бизнеса

Аудит и безопасность мобильных приложений

Аудит и безопасность мобильных приложений

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

Да, чтобы противостоять хакерским угрозам, нужно частично пожертвовать удобством пользователя. Появятся пароли, подтверждения, проверки. Но, как говорит Андрей Брызгин, руководитель направления аудита и консалтинга безопасности Group-IB, безопасность удобной не бывает. Это значит, что между функциональными бизнес-требованиями и защищенностью нужно найти адекватный баланс.

Далеко не всегда разработчик, ориентированный в первую очередь на функционал приложения, способен сам разобраться в угрозах и уязвимостях. Поэтому лучший способ проверить защищенность создаваемого продукта – привлечь независимого аудитора. Уж Group-IB точно можно доверять в этом вопросе, ведь они анализируют уязвимости более 10 лет, понимают слабости инфраструктур любого масштаба и к каждой компании находят индивидуальный подход.

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

Существуют три базовых модели аудита безопасности:

1. Black box. Аудитор имеет тот же доступ, что и обычные пользователи приложения. Ему ничего неизвестно ни о компании, ни о самом приложении. Файлы приложения скачиваются из официального магазина.

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

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

Black box – самая распространенная модель аудита. Аудитор получает в буквальном смысле черный ящик с неизвестным содержимым и должен найти способ его вскрыть, достать содержимое, а затем еще и закрыть так, чтобы никто ничего не заподозрил. Именно по схеме «скачать приложение из магазина и взломать» происходит типичный взлом, поэтому Black box – рекомендуемый вид аудита для большинства приложений.

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

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

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

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

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

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

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

Оглавление книги