OPENID CONNECT
Мобильное приложение использует openidconnect с grant_type = client_credentials для получения токенов.
Для начала, как уже указывалось другими, это не правильный тип гранта для использования в мобильном приложении, вместо этого вы можете захотеть использовать поток authorization_code.
Подробнее о этой статье :
Теперь мы рассмотрим go минимальный пример того, как получить идентификационный токен для пользователя из OP, используя поток кода авторизации . Это наиболее часто используемый поток в традиционных веб-приложениях.
ИЗВЛЕЧЕНИЕ СЕКРЕТОВ
Тип предоставления 'client_credentials' требует client_id, client_secret в теле запроса. Если кто-то использует Fiddler для атаки как человек посередине, он может знать идентификатор / секрет клиента, тогда он может быть человеком посередине, используя их для получения токена доступа.
Учитывая это вы решаете реализовать правильный поток авторизации OpenID Connect для своего мобильного приложения, таким образом, больше не раскрывая ваш client_secret, злоумышленник может использовать Fidller для атаки MitM на ваше соединение и извлечь полученный токен Authorization для аутентификации пользователя мобильное приложение на сервере API, как я показал в статье Украсть этот ключ Api с человеком в средней атаке :
Чтобы помочь продемонстрировать, как украсть ключ API, я создал и выпустил на Github приложение Currency Converter Demo для Android, в котором используется тот же метод JNI / NDK , который мы использовали в более раннем Android Hide Secrets приложение для скрытия ключа API .
Итак, в этой статье вы узнаете, как настроить и запустить атаку MitM для перехвата https tra ffi c на мобильном устройстве под вашим контролем, чтобы вы могли украсть ключ API. Наконец, вы увидите на высоком уровне, как можно смягчить атаки MitM.
Хотя в этой статье показана атака с целью кражи ключа Api, принцип такой же, как и любой другой секрет или данные из запрос.
Злоумышленник также может прибегнуть к инструментарию, чтобы подключиться во время выполнения к коду вашего мобильного приложения и украсть из него любой секрет, и хорошим примером таких инструментов является Frida :
Внедряйте свои собственные сценарии в процессы черного ящика. Подключайте любую функцию, шпионите за криптографическими API или отслеживайте частный код приложения, исходный код не требуется. Отредактируйте, нажмите «Сохранить» и сразу увидите результаты. И все это без этапов компиляции или перезапуска программы.
ВОЗМОЖНЫЕ РЕШЕНИЯ
Итак, как предотвратить этот случай атаки?
Предотвращение атак в клиент возможен до некоторой степени, но в конечном итоге у вас нет возможности увидеть, когда злоумышленники могут обойти меры безопасности, которые вы отправили в APK вашего мобильного приложения, потому что, когда опытный злоумышленник знает, как правильно использовать инструментальную платформу он заглянет в код, который принимает решения по безопасности, и заставит его всегда возвращать, что все в порядке.
Вместо этого вы хотите сместить фокус на то, чтобы ваш сервер API мог надежно знать, что действительно разговаривает с тот же самый APK, который вы выпустили, без подделки и взлома, или того, что запросы исходят от бота.
Аттестация мобильного устройства
С момента выпуска DeviceCheck для iOS и Safet yNet для Android, я вижу больше и мес. re разработчики ссылаются на них как на форму подтверждения своих мобильных приложений, но некоторые не могут понять, для чего на самом деле предназначены эти решения.
Возьмем собственные слова Google о Safet yNet:
Использование Safet yNet Результаты аттестации API как единственный сигнал для атаки на злоупотребления
Может возникнуть соблазн подумать, что Safet yNet Attestation API предоставляет все необходимые сигналы для защиты приложения от злоумышленников и использует их как единственный сигнал для построения системы защиты от злоупотреблений.
API аттестации Safet yNet может подавать только сигналы о состоянии устройства, но не о намерениях пользователя, которые должна определять система защиты от злоупотреблений. Следовательно, вы можете рассмотреть возможность включения других сигналов, таких как журналы доступа и поведенческие шаблоны, для более точного обнаружения оскорбительных пользователей и рассмотреть возможность не блокировать пользователей только при неудачной аттестации. Кроме того, существует множество других условий, которые приводят к сбою аттестации, например, проблемы с сетевым подключением, проблемы с квотами и другие временные проблемы.
Другими словами, не все пользователи, не прошедшие аттестацию, обязательно являются нарушителями, и не все злоумышленники обязательно не пройдут аттестацию. Блокируя пользователей только по результатам их аттестации, вы можете упускать оскорбительных пользователей, которые не проходят аттестацию. Кроме того, вы также можете блокировать законных, лояльных клиентов, которые не проходят аттестацию по причинам, отличным от злоупотреблений.
Я более подробно рассказываю о том, что разработчик должен знать, в этом ответе на вопрос Android эквивалент ios devicecheck .
Итак, суть в том, что в случае Safet yNet он подтверждает мобильное устройство, а не ваше мобильное приложение, но все же наличие надежного механизма безопасности.
Для подтверждения того, что мобильное приложение действительно не является компромиссом или злоупотреблением, вам необходимо использовать решение для аттестации мобильных приложений.
Аттестация мобильного приложения
Роль аттестации мобильного приложения заключается в том, чтобы подтвердить, что загружаемый вами APK не подвергается риску взлома или еще не скомпрометирован, что позволяет вашему серверу API иметь высокую степень уверенности, которая действительно взаимодействует с подлинным экземпляром вашего мобильное приложение.
Я приглашаю вас прочитать этот ответ Я дал еще один вопрос n, который объясняет концепцию более подробно и в то же время дает вам больше контекста, почему это может быть лучше для решения вашей проблемы.
Итак, если вы объедините аттестацию мобильного приложения с аттестацией мобильного устройства, тогда вы возможно, нашли лучшее решение для защиты вашего мобильного приложения от злоупотреблений из-за скомпрометированных учетных данных OAuth.
ХОТИТЕ GO ДОПОЛНИТЕЛЬНАЯ МИЛЯ? Мне всегда нравится ссылаться на замечательную работу фонда OW ASP, поэтому вот оно: для мобильных приложений OW ASP Mobile Security Project - 10 основных рисков OW ASP Mobile Security Project - это централизованный ресурс, предназначенный для предоставления разработчикам и группам безопасности ресурсов, необходимых им для создания и поддержки безопасных мобильных приложений. В рамках проекта наша цель состоит в том, чтобы классифицировать риски мобильной безопасности и предоставить средства управления разработкой для снижения их воздействия или вероятности эксплуатации. OW ASP - Руководство по тестированию мобильной безопасности : The Mobile Security Testing Guide (MSTG) - это подробное руководство по разработке, тестированию и обратному проектированию безопасности мобильных приложений. Для APIS OW ASP Топ 10 по безопасности API Проект безопасности API OW ASP стремится предоставить ценность разработчикам программного обеспечения и специалистам по оценке безопасности, подчеркивая потенциальные риски небезопасных API-интерфейсов и иллюстрируя, как можно уменьшить эти риски. Чтобы способствовать достижению этой цели, OW ASP API Security Project создаст и будет поддерживать документ «Топ-10 рисков безопасности API», а также портал документации для передовых методов создания или оценки API.