Темное искусство создания мобильного приложения корпоративного уровня — часть 3
Этот пост является третьим в серии постов, которые частично являются инструкциями и частично журналом, в которых рассказывается о моем пути к разработке мобильных приложений в течение последние 18 месяцев.
Вы можете ознакомиться с частями 1 и 2 по ссылкам ниже:
Часть 1: Введение и выбор правильной технологии
Часть 2: Объяснение проблем, связанных с мобильными устройствами
Давайте поговорим о плохих парнях!
Нервным аспектом разработки мобильного программного обеспечения является публикация вашего кода в открытом доступе, зная, что с ним могут случиться плохие вещи. Здесь нет ни брандмауэра, ни физической защиты, как защищенный дата-центр. Любой может декомпилировать приложение и проверить код. Устройства теряются и часто попадают не в те руки. Вредоносные программы или мошеннические приложения, установленные на устройстве, также могут искать потенциальные слабые места. (аналогия антитезы в части 2!)
В этой статье мы рассмотрим различные аспекты мобильной безопасности с учетом одного принципа — Эшелонированная защита. Ни одна функция безопасности не является надежной сама по себе, но вместе они обеспечивают надежную защиту.
Если есть один ключевой вывод из этой статьи —
Безопасность — это не функция! Безопасность — это не отдельная история или элемент невыполненной работы. Он должен быть неотъемлемой частью процесса разработки.
Когда риски безопасности выявляются ближе к концу разработки функций, мы обнаружили, что они часто отрицательно сказываются на сроках выпуска, а их исправление и повторное тестирование обходятся дорого.
Введение в мобильную криминалистику
Чтобы полностью понять уровень проверки, которую может пройти мобильное приложение, давайте кратко рассмотрим науку, лежащую в основе извлечения цифровых доказательств с телефонов, — Мобильная криминалистика.
Существуют разные способы извлечения данных с мобильного устройства, от очень простых до очень сложных.
логический анализ включает в себя подключение USB-кабеля или Bluetooth к устройству для извлечения данных. Шестнадцатеричный дамп — это извлечение дампа памяти телефона и его последующий анализ с помощью дополнительного программного обеспечения, которое даже позволяет восстанавливать удаленные файлы. Прочитав книгу о мобильной криминалистике, я понял, что для расширенного извлечения требуется физический доступ к устройству.
Не пишите на устройстве ничего, что подвергает фирму риску. Предоставьте пользователям возможность отменить регистрацию своего приложения в случае его потери.
Что такое пентестинг и зачем он нам нужен?
Пентест или тестирование на проникновение — это своего рода этичный взлом мобильного приложения. Мы передаем ключи от дома некоторым хорошим парням, которые делают плохие вещи в приложении, и подчеркиваем риски и уязвимости, которые всплывают. Это дает нам определенную уверенность в отношении уязвимостей системы безопасности и утечек данных.
Существует два вида пентестинга: черный ящик и белый ящик.
Пен-тестирование проходит в несколько этапов продолжительностью около 2-3 недель. Тестировщики анализируют кодовую базу, используемые сторонние библиотеки, изучают Интернет, социальные сети и переполнение стека на наличие известных уязвимостей. Они также устанавливают приложение на набор устройств и перехватывают входящий и исходящий трафик. Установите и удалите приложение, проверьте оставшиеся данные и т. д.
Мобильная команда получает отчет с изложением риска и соответствующих уровней угрозы в конце всего этого.
Знание требований безопасности во время разработки, наличие программного обеспечения для сканирования кода и строгий контроль качества, интегрированный с коммитами git, сэкономит много времени и усилий.
Защита приложения
Обнаружение джейлбрейка или рута (и почему это проблема)
Это механизм определения того, взломано ли устройство (iOS) или рутировано (Android), и ограничения определенных функций приложения или полного прекращения работы приложения. Устройства Apple уже не так просты для джейлбрейка, и у них есть механизм самоисправления после подключения к Интернету. Устройства Android, однако, немного отличаются; некоторые устройства продаются с root-доступом. Полная их остановка может помешать части пользовательской базы получить доступ к приложению. Так что это уравновешивание.
Почему это проблема?
Целостность песочницы приложения нарушена. Мошенническое приложение может получить разрешения на чтение файловой системы приложения и безопасного хранилища.
Всегда выполняйте шифрование перед записью любых данных на устройство.
Э-э, нет смысла шифровать, если вы оставите мастер-ключ без присмотра. Я просто говорю".
Другие аспекты мобильной безопасности
Обфускация кода — запретить декомпиляторам читать код приложения.
Обнаружение отладчика — предотвращение запуска приложения в режиме отладки, сделанное для обратного проектирования логики приложения.
Если вам интересна эта тема, рекомендую прочитать отчет Verizon Mobile Security Index (MSI) 2020 здесь.
Защита транспортного уровня
Цель состоит в том, чтобы предотвратить перехват трафика между приложением и предприятием. Хуже того, они притворяются, что они являются предприятием, обманом заставляя пользователя предоставить конфиденциальную информацию, такую как данные кредитной карты или информацию о банковском счете. Причудливое название того, что вот-вот произойдет, называется атака «человек посередине».
Я знаю, что вы думаете; мы будем использовать HTTPS. Удерживайте эту мысль.
Повторение того, как работает HTTPS
Каждый веб-сайт, даже удаленно профессиональный, использует HTTPS для связи с браузером, и мы воспринимаем это как должное. Давайте кратко рассмотрим, как это работает.
Какой цели служит HTTPS?
- Он шифрует трафик — это просто. Происходит сложный обмен информацией и ключами, когда браузер инициирует запрос, который является основой для дальнейшего общения.
2. Проверяет личность сервера — бремя доказательства лежит на сервере и основано на цифровой подписи и цепочке доверия. У каждого браузера в мире есть список доверенных корневых сертификатов. (убедиться в этом можно в разделе безопасность браузера -> управление сертификатами)
Вы словно спрашиваете , кто вы такой, чтобы писать эту статью? Почему мы должны верить всему, что вы говорите? Действительный вопрос.
Ваш приятель говорит: Ну, это Сундар, работает на парня по имени Джас; он считает, что с ним все в порядке.
Кто такая Джас?
Ну, вы знаете парня, который работает на Дано.
Кто такой Дано?
Он работает на Росса, руководителя NAB.
Вы говорите:О! Все доверяют Россу, так что с Сундаром все в порядке!
И именно в этом проблема! Цепочка доверия открыта для злоупотреблений и вызвала множество серьезных инцидентов безопасности.
Как мы решим проблему? Разорвав цепочку доверия, конечно!
Аналогию с браузером мы проведем во второй части! Приложение — это прославленный браузер, который взаимодействует с одним веб-сайтом, но браузер должен делать гораздо больше. Он должен общаться с миллионами веб-сайтов, в том числе с некоторыми очень сомнительными. Он опирается на цепочку доверия, чтобы провести различие. Что, если приложение возьмет на себя ответственность за доверие к самому серверу (предприятию, с которым оно предназначено для связи)?
Закрепление сертификата
Чтобы повторить, как браузеры поставляются со встроенными корневыми сертификатами, мы можем упаковать приложение с цифровой подписью предприятия, чтобы убедиться, что это действительно предприятие. Это верный вариант. Единственным недостатком является то, что при изменении сертификатов (и впоследствии подписей) каждый раз необходимо выпускать новое приложение!
Другой вариант — загружать ключ из отдельной конечной точки каждый раз при инициализации приложения. Это, возможно, медленнее, поскольку это дополнительный вызов API, но у него есть дополнительное преимущество, заключающееся в разделении приложения и уровня безопасности. Если вы думаете, если злоумышленник может перехватить конечные точки API, он также может подделать конечные точки сертификата? Прелесть криптографии с асимметричным ключом и алгоритма хеширования означает, что если содержимое файла сертификата изменено, приложение может легко распознать его.
Обнаружение и блокировка незащищенных каналов связи и уведомление пользователя.
Защита на краю
Мы углубимся в одну тему — Обнаружение ботов
Обнаружение ботов
Если закрепление сертификата направлено на то, чтобы остановить плохие объекты, выдающие себя за предприятие, то обнаружение ботов противоположно этому. Плохие боты — это вредоносное ПО, выдающее себя за мобильные приложения.
Боты в современном мире
Плохие боты могут нанести большой урон. Они могут запускать автоматические атаки, такие как отказ в обслуживании. Они могут добывать учетные данные, собирать ценный контент, сканировать на наличие уязвимостей и делать кучу других неприятных вещей. Боты стали настолько изощренными, что они очень точно имитируют поведение пользователя. Их можно запускать с резидентных IP-адресов, при этом каждый IP-адрес используется всего несколько раз. (из места, близкого к реальному пользователю!) Они устанавливаются на реальные мобильные устройства в составе крупных ферм устройств и даже могут обходить проверки капчи.
Когда дело доходит до обнаружения ботов, это настоящая гонка вооружений.
Как работают детекторы ботов?
Детекторы ботов используют комбинацию известных сигнатур ботов, поведенческого анализа, заголовков HTTP, мобильных отпечатков пальцев и передают их в передовые модели машинного обучения, чтобы сделать прогноз. Эти модели постоянно дорабатываются и развертываются на периферии. Чтобы помочь в обнаружении ботов, приложению необходимо дополнить детектор ботов дополнительными данными, такими как отпечатки пальцев устройства и данные датчика. Как правило, это делается с помощью SDK, встроенного в приложение.
Как эти данные хотя бы отдаленно полезны? Представьте, как человек использует устройство по сравнению с программным обеспечением.
Везде, от катания в постели до прокрутки в трусах, у нас есть способ использования телефона, который боты не могут имитировать.
Один из способов просмотра данных датчика (таблица выше) — это вектор в 10-мерном пространстве (-0,484, 3,7, 4,8, -0,102, -0,80, 0, 1, 1, 0), а детектор ботов — матрица. Это так же просто, как умножение матрицы на вектор, хотя и в многомерном пространстве, а люди и боты разделены гиперплоскостью! В конце концов, все сводится к одной математической операции, поэтому они такие быстрые и работают с задержкой менее миллисекунды.
Дополнительная литература по защите серверной части
Безопасность API — горячая тема! Полный объем защиты API-интерфейсов немного выходит за рамки этой статьи, но я хотел бы оставить вас с отчетом Gartner о циклах шумихи по безопасности приложений. (Это издание 2019 года, и оно общедоступно, но немного устарело, 2020 год, который мы рассмотрели, немного изменился)
Этот пост является третьим в серии постов, которые частично состоят из инструкций и частично из журнала, описывающего мой путь разработки мобильных приложений за последние 18 месяцев.
Часть 1: Введение и выбор правильной технологии
Часть 2: Объяснение проблем, связанных с мобильными устройствами
Часть 3. Безопасность приложения, транспорта и API
