Ваш текущий подход
Мой текущий подход заключается в том, чтобы вычислить сигнатуру приложения (C-код) и сравнить ее с массивом сигнатур, которые были загружены с сервера.
Мне нужно предупредить вас о том, что в рутированном телефоне злоумышленник сможет перехватить ваш код во время выполнения и изменить его поведение, это означает, что ваша логика для определения правильности подписи всегда будет возвращатьсяtrue.Они делают это, используя интроспективный фреймворк, такой как Frida :
Внедрение собственных сценариев в процессы черного ящика.Подключите любую функцию, следите за крипто-API или отслеживайте частный код приложения, исходный код не требуется.Отредактируйте, нажмите «Сохранить» и мгновенно увидите результаты.Все без шагов компиляции или перезапуска программы.
Ваше требование
У меня есть требование, что подпись моего приложения Swift для iOS должна быть проверена.Я думаю, что это актуально только для взломанных устройств, так как iOS сама проверяет целостность.
Хорошо, если это требование предназначено только для защиты вашего приложения от запуска на рутированном устройстве, проверки подписи приложения недостаточно, как только устройство рутировано, любое приложение на нем может бытьлегко манипулировать, как я уже упоминал.Защита приложения от атак на само устройство является непростой задачей, и все равно что играть в игру в кошки-мышки с атакующими, пытаясь не отставать от игры.Вам необходимо использовать защиту приложений, чтобы определить, работает ли приложение на сломанном устройстве, подключена ли система интроспекции, запущена ли в эмуляторе, подключен ли отладчик и т. Д. Это бесконечная игра сЗлоумышленники, и у них есть огромное преимущество, они могут посвятить все свои ресурсы и время, чтобы сломать ваше приложение, если оно того стоит, но у вас могут не быть таких же человеческих ресурсов, времени и денег, чтобы инвестировать в эту игру.Независимо от того, как вы решите играть в игру, вы всегда можете прибегнуть к Apple Device Check API , чтобы указать на сервере API, что конкретное устройство не заслуживает доверия.
В случае требования кубедитесь, что подпись приложения iOS более соответствует защите сервера API от получения запросов от приложения iOS, которое не является подлинным, которое вы загрузили в магазин Apple, тогда может быть возможно лучшее решение, известное по названиюаттестации мобильного приложения.Так что, если это также входит в сферу ваших требований, вы должны продолжать читать, в противном случае просто пропустите это.
Прежде чем углубиться в концепцию аттестации мобильных приложений, я хотел бы сначала прояснить ошибочное представление о WHO и ЧТО обращается к серверу API.
Разница между ВОЗ и ЧТО имеет доступ к серверу API
Чтобы лучше понять различия между WHO и ЧТО обращаются к серверу API, давайте использовать этокартинка:
Поэтому замените мобильное приложение веб-приложением и продолжайте следовать моей аналогии с этой картинкой.
Предполагаемый канал связи представляет собой веб-приложениеиспользуется, как и ожидалось, законным пользователем без каких-либо злонамеренных намерений, связываясь с сервером API из браузера, не используя Postman или используя любой другой инструмент для выполнения атаки «человек посередине» (MitM).
Фактический канал может представлять несколько различных сценариев, например, законный пользователь со злонамеренными намерениями, который может использовать Curl или инструмент, такой как Postman, для выполнения команды.Например, хакер, использующий инструмент атаки MitM, такой как MitmProxy, чтобы понять, как осуществляется связь между веб-приложением и сервером API, чтобы иметь возможность воспроизводить запросы или даже автоматизировать атаки на сервер API.Возможны многие другие сценарии, но мы не будем перечислять здесь каждый.
Я надеюсь, что к настоящему времени у вас уже может быть ключ к пониманию того, почему WHO и WHAT не совпадают, но если нет, то это станет ясно через мгновение.
WHO является пользователем веб-приложения, которое мы можем аутентифицировать, авторизовывать и идентифицировать несколькими способами, например, используя OpenID Connect или потоки OAUTH2.
OAUTH
Как правило, OAuth предоставляет клиентам «безопасный делегированный доступ» к ресурсам сервера от имени владельца ресурса.Он определяет процесс для владельцев ресурсов, чтобы разрешить сторонний доступ к своим ресурсам сервера без совместного использования своих учетных данных.Разработанный специально для работы с протоколом гипертекстовой передачи (HTTP), OAuth, по сути, позволяет выдавать маркеры доступа сторонним клиентам с помощью сервера авторизации с разрешения владельца ресурса.Затем третья сторона использует токен доступа для доступа к защищенным ресурсам, размещенным на сервере ресурсов.
OpenID Connect
OpenID Connect 1.0 представляет собой простой слой идентификации поверхпротокол OAuth 2.0.Это позволяет клиентам проверять подлинность конечного пользователя на основе аутентификации, выполняемой сервером авторизации, а также получать базовую информацию о профиле конечного пользователя взаимодействующим и REST-подобным образом.
Хотя аутентификация пользователя может сообщить серверу API, что WHO использует API, она не может гарантировать, что запросы были получены из ожидаемого WHAT браузера, в котором ваше веб-приложение должноработать с реальным пользователем.
Теперь нам нужен способ определить, ЧТО вызывает API-сервер, и здесь все становится сложнее, чем может подумать большинство разработчиков. WHAT - это то, что делает запрос к серверу API.Действительно ли это подлинный экземпляр веб-приложения, или это бот, автоматизированный скрипт или злоумышленник, работающий вручную с API-сервером и использующий такой инструмент, как Postman?
К вашему удивлению, вы можете оказаться в конечном итогеобнаружив, что это может быть один из законных пользователей, манипулирующих запросами вручную или с помощью автоматического сценария, который пытается геймифицировать и воспользоваться услугой, предоставляемой веб-приложением.
Ну, чтобы определить ЧТО, разработчики, как правило, прибегают к API-ключу, который обычно отправляется в заголовках веб-приложения.Некоторые разработчики делают все возможное и вычисляют ключ во время выполнения в веб-приложении, внутри запутанного javascript, таким образом, он становится секретом времени выполнения, который может быть подвергнут обратному проектированию с помощью инструментов устранения сбоев и проверки трафика между веб-приложением и APIсервер с инструментами F12 или MitM.
Приведенная выше статья взята из написанной мною статьи под названием ПОЧЕМУ ВАШЕМУ МОБИЛЬНОМУ ПРИЛОЖЕНИЮ НУЖЕН КЛЮЧ API? .Хотя в контексте мобильного приложения общая идея остается в силе в контексте веб-приложения.Вы хотите, чтобы вы могли прочитать статью полностью здесь , это первая статья в серии статей о ключах API.
Аттестация мобильного приложения
ИспользованиеРешение Mobile App Attestation позволит серверу API знать, ЧТО отправляет запросы, что позволяет отвечать только на запросы от подлинного мобильного приложения, отклоняя все другие запросы из небезопасных источников.
Роль решения для аттестации мобильных приложений состоит в том, чтобы во время выполнения гарантировать, что ваше мобильное приложение не было взломано, не запущено на корневом устройстве, не оснащено инструментарием, таким как Frida, не подвергается атаке MitM, и это достигаетсязапустив SDK в фоновом режиме.Служба, работающая в облаке, будет бросать вызов приложению, и на основе ответов она будет подтверждать целостность мобильного приложения и устройства, на котором оно работает, поэтому SDK никогда не будет нести ответственность за любые решения.
MiTM Proxy
Интерактивный перехватывающий 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 Project - 10 основных рисков
OWASP Mobile Security Project - это централизованный ресурс, предназначенный для предоставления разработчикам и командам безопасности ресурсов, необходимых для создания и поддержки защищенных мобильных приложений.В рамках проекта наша цель состоит в том, чтобы классифицировать риски безопасности мобильных устройств и обеспечить средства контроля развития, чтобы уменьшить их влияние или вероятность эксплуатации.