Метод токена
Поправьте меня, если я ошибаюсь, в наши дни MobileApps согласно дизайну использует метод токена сеанса для запроса.
Я думаю, что вы имеете в виду токены OAUTH2 или OpenID.
OAUTH2
OAuth 2.0 фокусируется на простоте разработки для клиента, в то время какпредоставление определенных потоков авторизации для веб-приложений, настольных приложений, мобильных телефонов и устройств в жилых помещениях.
OpenID
OpenID Connect 1.0 - это простоеуровень идентификации поверх протокола OAuth 2.0.Это позволяет клиентам проверять подлинность конечного пользователя на основе аутентификации, выполняемой сервером авторизации, а также получать базовую информацию о профиле конечного пользователя взаимодействующим и REST-подобным образом.
OpenID Connect позволяет клиентам всех типов, включая веб-клиенты, мобильные клиенты и клиенты JavaScript, запрашивать и получать информацию об аутентифицированных сеансах и конечных пользователях.Набор спецификаций расширяем, позволяя участникам использовать дополнительные функции, такие как шифрование идентификационных данных, обнаружение поставщиков OpenID и управление сеансами, когда это имеет для них смысл.
Идентификация мобильного приложения в API
В настоящее время пользователь впервые передает свой идентификатор устройства, пин-код и метку времени для зашифрованного значения из серверной части.Впоследствии интерфейсная система отправит этот параметр для запроса и получит ответ успешно.Срок действия токена 30 минут.
Обычно разработчики идентифицируют мобильное устройство для сервера API с помощью секрета, который обычно называется api-key или какого-то токена *-token.Независимо от того, какое имя соглашения используется, этот идентификатор всегда является секретом, который иногда представляет собой простую уникальную строку для идентификации мобильного приложения, а иногда более сложную, как в вашем случае.
С недавним событиемХакеры могут манипулировать запросом из скрипта путем подмены.
Проблема в том, что все, что работает на стороне клиента, может быть легко взломано злоумышленником на устройстве, которым он управляет.Он будет использовать структуры самоанализа, такие как Frida или xPposed , чтобы перехватывать во время выполнения исполняемый код мобильного приложения, или будет использовать прокси-инструмент, такой как MiTM, для наблюдения за связями между мобильным приложением иAPI сервер.Обычно их первым шагом в обратном инжиниринге мобильного приложения будет использование Mobile Security Framework для обратного инжиниринга двоичного файла вашего мобильного приложения для извлечения всех статических секретов и выявления векторов атак.
Фрида
Внедрение собственных сценариев в процессы черного ящика.Подключите любую функцию, следите за крипто-API или отслеживайте частный код приложения, исходный код не требуется.Отредактируйте, нажмите «Сохранить» и мгновенно увидите результаты.Все без шагов компиляции или перезапусков программы.
xPposed
Xposed - это фреймворк для модулей, который может изменять поведение системы и приложений, не касаясь каких-либо APK.Это здорово, потому что это означает, что модули могут работать для разных версий и даже ПЗУ без каких-либо изменений (если исходный код не был слишком изменен).Отменить также просто.
Mobile Security Framework
Mobile Security Framework - это автоматизированное мобильное приложение "все в одном" (Android /iOS / Windows) фреймворк для ручного тестирования, позволяющий выполнять статический анализ, динамический анализ, анализ вредоносных программ и тестирование веб-API.
MiTM Proxy
Интерактивный HTTP-прокси с поддержкой TLS для тестировщиков проникновения и разработчиков программного обеспечения.
Таким образом, после использования всех этих инструментов злоумышленник может воспроизвести все шаги, которые выполняет ваше мобильное приложение, чтобы получить токен с сервера API и впоследствии использовать его для автоматизации атак на сервер API.
Возможное решение
Так что хакеры имитируют то же поведение, что и в мобильных приложениях. Как мы обслуживаем такой сценарий? Есть ли способ заблокировать такой запрос?
Таким образом, все, что работает на стороне клиента и нуждается в некотором секрете для доступа к API, может быть использовано по-разному, и вы можете узнать больше о этой серии статей о технологиях безопасности мобильных API. В этой статье вы узнаете, как можно использовать ключи API, токены доступа пользователей, HMAC, TLS Pinning для защиты API и как их можно обойти.
Лучшее решение можно использовать с помощью решения для аттестации мобильных приложений, чтобы сервер API мог знать, что он получает запросы только от подлинного мобильного приложения.
Служба аттестации мобильных приложений гарантирует во время выполнения, что ваше мобильное приложение не было взломано или не работает на рутированном / взломанном устройстве, запустив SDK в фоновом режиме (без влияния на взаимодействие с пользователем), которое будет взаимодействовать с служба, работающая в облаке для подтверждения целостности мобильного приложения и работающего устройства.
При успешной аттестации целостности мобильного приложения выдается кратковременный токен JWT, который подписывается с секретом, о котором знают только сервер API и служба аттестации мобильных приложений в облаке. В случае сбоя при аттестации мобильного приложения токен JWT подписывается секретом, которого сервер API не знает.
Теперь приложение должно отправлять при каждом вызове API токен JWT в заголовках запроса. Это позволит серверу API обслуживать запросы только тогда, когда он может проверить подпись и время истечения срока действия в токене JWT и отклонить их, если он не прошел проверку.
Как только секрет, используемый службой аттестации мобильных приложений, не известен мобильному приложению, его невозможно взломать во время выполнения, даже когда приложение подделано, работает на корневом устройстве или осуществляет связь через соединение, которое является целью человека в средней атаке.
Сервис аттестации мобильных приложений уже существует в качестве решения SAAS на Approov (я работаю здесь), который предоставляет SDK для нескольких платформ, включая iOS, Android, React Native и другие. Для интеграции также потребуется небольшая проверка кода сервера API для проверки токена JWT, выпущенного облачной службой. Эта проверка необходима для того, чтобы сервер API мог решать, какие запросы обслуживать, а какие отклонять. Ваш текущий токен может использоваться в качестве утверждения полезной нагрузки в токене Approov, чтобы позволить серверу API продолжать использовать его с гарантией, которая не была подделана.