СЕРВЕР API НЕ МОЖЕТ ДОВЕРЯТЬ В ЗАПРОСАХ
И поскольку запрос включает ключ API, сервер будет доверять запросу и отвечать маркером входа.
Сервер API не может доверять никаким запросам, которые он получает, основываясь только на ключе API, потому что их так легко извлечь из мобильного приложения с помощью инструментов обратного инжиниринга, которые мы можем найти в сообществе открытого исходного кода.
Чтобы лучшеЧтобы понять, почему мы не можем слепо доверять запросам, поступающим на сервер API, нам необходимо понять 2 понятия: WHO и ЧТО взаимодействует с сервером API.
WHO ANDЧТО ДОСТУПАЕТ К СЕРВЕРУ API
WHO - это пользователь мобильного приложения, которое можно аутентифицировать, авторизовать и идентифицировать несколькими способами, например, используя OpenID, потоки OAUTH2 или VoicePrint.
Но прежде чем вы узнаете WHO , вам нужен способ определить, ЧТО вызывает ваш API-сервер, и здесь все становитсяболее хитрый, чем может подумать большинство разработчиков. ЧТО - это то, что делает запрос к серверу API, действительно ли это ваше подлинное мобильное приложение, или это робот, автоматизированный скрипт или злоумышленник, вручную копающийся в вашем сервере API с помощью такого инструмента, как Postman?
Хорошо, чтобы определить ЧТО разработчики, как правило, прибегают к API-ключу, который обычно они жестко кодируют в коде своего мобильного приложения, а некоторые прилагают дополнительные усилия и вычисляют его во время выполнения.в мобильном приложении, таким образом, становится динамическим секретом в отличие от прежнего подхода, который представляет собой статический секрет, встроенный в код.думал об использовании своего рода API-ключа, возможно, генерируя случайную строку и распространяя ее вместе с приложением.
Правда в том, что все, что работает на стороне клиента, может быть легко взломано злоумышленником на устройстве, которым он управляет.Он будет использовать рамки для самоанализа, такие как Frida или xPposed , чтобы перехватывать во время выполнения работающий код мобильного приложения, или будет использовать прокси-инструмент, такой как MiTM Proxy для просмотрасвязь между мобильным приложением и сервером API.Обычно их первым шагом в обратном инжиниринге мобильного приложения будет использование Mobile Security Framework для обратного инжиниринга двоичного файла вашего мобильного приложения для извлечения всех статических секретов, или ключа API, и для определения других векторов атак..
Если проверка голосовых отпечатков происходит локально в мобильном приложении, как вы позволите серверу безопасно знать, что пользователь проверен?
Таким образом, выполнение этой проверки на стороне клиента открывает векторную атаку использования XPposed, Frida или даже MobSF во время выполнения для фальсификации результатов голосовой проверки.
Помните, что пользователи вДля получения бесплатного Wi-Fi можно обмануть установку вредоносных приложений или пользовательских ssl-сертификатов, что позволит злоумышленнику проанализировать, перехватить и изменить решения, принимаемые на устройстве, и манипулировать данными, передаваемыми по проводной связи на сервер API.другими словами, они могут обойти результаты распознавания голосовых отпечатков.
Mobile Security Framework
Mobile Security Framework - это автоматизированное многофункциональное устройство.фреймворк для тестирования мобильных приложений (Android / iOS / Windows), позволяющий выполнять статический анализ, динамический анализ, анализ вредоносных программ и тестирование веб-API.
Frida
Внедрение собственных сценариев в процессы черного ящика.Подключите любую функцию, следите за крипто-API или отслеживайте частный код приложения, исходный код не требуется.Отредактируйте, нажмите «Сохранить» и мгновенно увидите результаты.Все без шагов компиляции или перезапуска программы.
xPposed
Xposed - это фреймворк для модулей, который может изменять поведение системы и приложений, не касаясь каких-либо APK.Это здорово, потому что это означает, что модули могут работать для разных версий и даже ПЗУ без каких-либо изменений (если исходный код не был слишком изменен).Его также легко отменить.
MiTM Proxy
Интерактивный протокол TLS с возможностью перехвата HTTP-прокси для тестеров проникновения и разработчиков программного обеспечения.
ВОЗМОЖНОЕ РЕШЕНИЕ
Таким образом, все, что работает на стороне клиента и использует некоторый секрет для доступа к серверу API, может быть использовано неправильно, и вы можете узнать больше о этой серии статей о технологиях безопасности Mobile API.В этих статьях вы узнаете, как можно использовать ключи API, токены доступа пользователей, HMAC и TLS Pinning для защиты API и как их можно обойти.
Хотя это решение не очень убедительно.
Чтобы решить проблему доступа WHAT к вашему мобильному приложению, вам нужно использовать одно или все решения, упомянутые в серии статей о технологиях безопасности Mobile API, о которых я упоминал выше.и признал, что они могут сделать несанкционированный доступ к вашему серверу API только труднее, но не невозможным.Это означает, что, хотя еще труднее обойти результат распознавания голосовых отпечатков.
Есть ли способ войти в систему с помощью голосовой печати, когда проверка происходит внутри приложения?
Как яКак уже упоминалось ранее, любые решения, принимаемые на устройстве, могут быть изменены во время выполнения, поэтому для мобильной связи с сервером API для входа пользователя в систему на основе этого решения необходимо учитывать, что им можно манипулировать, чтобы обойти распознавание голосовых отпечатков..
Просто чтобы прояснить ситуацию, обход может произойти на самом устройстве, манипулируя во время выполнения возвращаемым результатом проверки голосовой отпечатка всегда true или перехватывая связь с сервером API и изменяя результатраспознавание голоса должно быть всегда true.
Из ваших комментариев в вопросе:
Это должно быть сделано на устройстве.Мы избегаем отправки голосовых данных на сервер для конфиденциальности пользователя.Если кто-то может украсть ваш пароль, вы можете просто изменить его.Но вы не можете сделать то же самое для своего голоса.
Теперь, когда вы знаете, что во время выполнения распознавание голосовых отпечатков может быть подделано, вредоносное ПО, которое делает это, также может извлекать результаты и отправлять их обратно злоумышленнику, что ставит под угрозу распознавание голоса.правильно сказал, что пользователь не может измениться.
Пока не убежден, пожалуйста, прочитайте его Биометрия может заменить наши пароли - и на самом деле есть большая проблема с этим , где вы можете прочитать, например:
Но нарушение биометрии имеет еще более серьезные последствия.Если кто-то завладеет вашими отпечатками пальцев, он может украсть вашу личность.
Чтобы помочь в передаче результатов распознавания голосовых отпечатков на сервер API, можно использовать решение для аттестации мобильных приложений.Это позволит серверу API знать, что он получает запросы только от подлинного мобильного приложения, которое не работает на устройстве с поврежденной корневой или тюрьмой, подключенном к инфраструктуре самоанализа или в режиме отладки.
Аттестация мобильного приложения
Используйте решение для аттестации мобильных приложений, чтобы сервер API мог знать, ЧТО отправляет запросы, что позволяет ему отвечать только на запросы от подлинного мобильного приложения.
Рольслужбы аттестации мобильных приложений заключается в том, чтобы гарантировать во время выполнения, что ваше мобильное приложение не было взломано или не запущено на корневом устройстве, запустив SDK в фоновом режиме, который будет взаимодействовать со службой, работающей в облаке, чтобы подтвердить целостностьмобильное приложение и устройство работают.
Вклуспешное подтверждение целостности мобильного приложения. Выпускается кратковременный токен JWT, который подписывается с секретом, о котором знают только сервер API и служба аттестации мобильных приложений в облаке.В случае сбоя при аттестации мобильного приложения токен JWT подписывается секретом, которого сервер API не знает.
Теперь приложение должно отправлять при каждом вызове API токен JWT в заголовках запроса.,Это позволит серверу API обслуживать запросы только в том случае, если он может проверить подпись и время истечения срока действия в токене JWT и отклонить их, если он не прошел проверку.
Как только секрет, используемый службой аттестации мобильных приложений, не являетсяизвестное мобильному приложению, невозможно выполнить его реинжиниринг во время выполнения, даже когда приложение подделано, работает на корневом устройстве или обменивается данными по соединению, являющемуся целью человека в средней атаке.
сервер будет доверять запросу и отвечать маркером входа.
Таким образом, с этим решением сервер API может доверять запросу мобильного приложения, говорящему о том, что распознавание голосадопустимо, таким образом, он может выдать токен аутентификации пользователя, который будет использоваться в последующих сеансах связи с сервером API.
Служба аттестации мобильных приложений уже существует в виде решения SAAS на Approov (я работаю здесь), который предоставляет SDK для несколькихплатформы, включая iOS, Android, React Native и другие.Для интеграции также потребуется небольшая проверка кода сервера API для проверки токена JWT, выпущенного облачной службой.Эта проверка необходима для того, чтобы сервер API мог решать, какие запросы обслуживать, а какие отклонять.