Ваш текущий подход

Мой текущий подход состоит в том, чтобы вычислить подпись приложения (C-код) и сравнить ее с массивом подписей, которые были загружены с сервера.

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

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

Ваше требование

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

Что ж, если это требование направлено только на защиту вашего приложения от запуска на рутованном устройстве, проверки подписи приложения недостаточно, поскольку после рутирования устройства любое приложение на нем можно легко манипулировать, как я уже упоминал. Защита приложения от атак на само устройство — непростая задача, и это похоже на игру в кошки-мышки с злоумышленниками, пытающуюся опередить игру. Вам нужно будет использовать средства защиты приложений, чтобы определить, работает ли приложение на взломанном устройстве, подключена ли структура самоанализа, работает ли оно в эмуляторе, подключен ли отладчик и т. д. Это бесконечная игра с злоумышленники, и у них есть огромное преимущество, они могут посвятить все свои ресурсы и время, чтобы сломать ваше приложение, если это того стоит для них, но у вас может не быть таких же человеческих ресурсов, времени и денег, чтобы инвестировать в эту игру. Независимо от того, как вы решите играть в игру, вы всегда можете воспользоваться Apple Device Check API, чтобы отметить на сервере API, что конкретное устройство не заслуживает доверия.

Если требование проверки подписи приложения iOS больше соответствует защите сервера API от получения запросов от приложения iOS, которое не является подлинным, которое вы загрузили в магазин Apple, тогда возможно лучшее решение, и оно известный под названием Mobile APP Attestation. Поэтому, если это также входит в сферу ваших требований, вы должны продолжать читать, в противном случае просто пропустите это.

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

Разница между КТО и ЧТО заключается в доступе к серверу API

Чтобы лучше понять разницу между КТО и ЧТО обращаются к серверу API, воспользуемся этим рисунком:

Так что замените мобильное приложение веб-приложением и продолжайте следовать моей аналогии с этой картинкой.

Предполагаемый коммуникационный канал представляет собой веб-приложение, используемое, как вы ожидали, законным пользователем без каких-либо злонамеренных намерений, связывающееся с сервером API из браузера, без использования Postman или любого другого инструмента для выполнения человека посередине (MitM) атака.

Фактический канал может представлять несколько различных сценариев, например, законный пользователь со злыми намерениями, который может использовать Curl или такой инструмент, как Postman, для выполнения запросов, хакер, использующий инструмент атаки MitM, такой как MitmProxy, чтобы понять, как связь между сетью приложение и сервер API выполняются для того, чтобы иметь возможность воспроизводить запросы или даже автоматизировать атаки на сервер API. Возможны и многие другие сценарии, но мы не будем здесь перечислять каждый из них.

Я надеюсь, что к настоящему времени вы, возможно, уже поняли, почему КТО и ЧТО не одно и то же, но если нет, то через мгновение станет ясно.

WHO — это пользователь веб-приложения, которого мы можем аутентифицировать, авторизовать и идентифицировать несколькими способами, например с помощью потоков OpenID Connect или OAUTH2.

OAUTH

Как правило, OAuth предоставляет клиентам безопасный делегированный доступ к ресурсам сервера от имени владельца ресурса. Он определяет процесс, с помощью которого владельцы ресурсов разрешают доступ третьих лиц к своим ресурсам сервера без предоставления своих учетных данных. Разработанный специально для работы с протоколом передачи гипертекста (HTTP), OAuth, по сути, позволяет серверу авторизации выдавать токены доступа сторонним клиентам с одобрения владельца ресурса. Затем третья сторона использует токен доступа для доступа к защищенным ресурсам, размещенным на сервере ресурсов.

Подключение OpenID

OpenID Connect 1.0 — это простой уровень идентификации поверх протокола OAuth 2.0. Это позволяет клиентам проверять личность конечного пользователя на основе аутентификации, выполняемой сервером авторизации, а также получать базовую информацию о профиле конечного пользователя совместимым и REST-подобным образом.

Хотя проверка подлинности пользователя может сообщить серверу API, КТО использует API, она не может гарантировать, что запросы были отправлены из ЧЕГО вы ожидаете, браузера, в котором должно быть ваше веб-приложение. работает от, с реальным пользователем.

Теперь нам нужен способ определить, ЧТО вызывает сервер API, и здесь все становится сложнее, чем может показаться большинству разработчиков. ЧТО — это то, что делает запрос к серверу API. Является ли это действительно подлинным экземпляром веб-приложения или это бот, автоматизированный скрипт или злоумышленник, который вручную копается в сервере API, используя такой инструмент, как Postman?

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

Ну, чтобы определить ЧТО, разработчики обычно прибегают к ключу API, который обычно отправляется в заголовках веб-приложения. Некоторые разработчики делают все возможное и вычисляют ключ во время выполнения в веб-приложении внутри запутанного javascript, таким образом, он становится секретом во время выполнения, который можно реконструировать с помощью инструментов деобуфракции и путем проверки трафика между веб-приложением и API. сервер с помощью инструментов F12 или MitM.

Приведенный выше текст взят из моей статьи под названием ПОЧЕМУ ВАШЕМУ МОБИЛЬНОМУ ПРИЛОЖЕНИЮ НУЖЕН КЛЮЧ API?. В то время как в контексте мобильного приложения общая идея по-прежнему актуальна в контексте веб-приложения. Если вы хотите, чтобы вы могли прочитать статью полностью здесь, это первая статья из серии статей о ключах API.

Аттестация мобильного приложения

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

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

Прокси MiTM

Интерактивный перехватывающий HTTP-прокси с поддержкой TLS для специалистов по тестированию на проникновение и разработчиков программного обеспечения.

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

Теперь приложение должно отправлять с каждым вызовом API токен JWT в заголовках запроса. Это позволит серверу API обслуживать запросы только тогда, когда он может проверить подпись и время истечения срока действия в токене JWT, и отклонить их, если проверка не пройдена.

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

Служба аттестации мобильных приложений уже существует в качестве решения SAAS в Approov (я здесь работаю), которая предоставляет SDK для нескольких платформ, включая iOS, Android, React Native и другие. Для интеграции также потребуется небольшая проверка в коде сервера API для проверки токена JWT, выданного облачной службой. Эта проверка необходима для того, чтобы сервер API мог решить, какие запросы обслуживать, а какие отклонять.

Резюме

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

Пройдя лишнюю милю

Проект OWASP Mobile Security — 10 основных рисков

Проект OWASP Mobile Security — это централизованный ресурс, предназначенный для предоставления разработчикам и специалистам по безопасности ресурсов, необходимых им для создания и обслуживания безопасных мобильных приложений. В рамках проекта наша цель состоит в том, чтобы классифицировать риски безопасности мобильных устройств и обеспечить контроль разработки, чтобы уменьшить их влияние или вероятность использования.