ВАША ПРОБЛЕМА
Обычно токен доступа действителен, скажем, в течение одного месяца.
Использование 1 месяца для истечения срока действия токена доступа - это долго, не имеет значения если для администратора или обычных пользователей.
В зависимости от вашего случая использования, я рекомендую вам использовать токены доступа со временем истечения в диапазоне минут, меньшее время, которое вы можете иметь лучше, будет для безопасности.
Поэтому я бы рекомендовал Вы можете переключиться на использование маркеров refre sh, которые сохранят токены доступа недолговечными, в то время как токены refre sh могут быть долгоживущими, но в диапазоне часов, а не дней, недель или лет.
Refre sh Пример потока токенов:
Источник: Mobile API Techniques - часть 2
ПРИМЕЧАНИЕ : хотя приведенная выше диаграмма c относится к серии статей, написанных в контексте мобильных API, в них содержится много информации, которая также подходит для API, обслуживающих веб-приложения, и третьи сторонние клиенты.
При использовании подхода маркеров refre sh, когда клиентский запрос не может проверить токен краткосрочного доступа, это будет означать, что клиент должен запросить новый, отправив refre * Токен 1196 *, чтобы получить новый токен недолговечного доступа.
Здесь важно отметить, что токен refre sh не следует отправлять в браузер, можно отправлять только токен доступа, поэтому ваш сторонние клиенты должны хранить приватные токены refre sh, то есть в своих бэкэндах, поэтому они НЕ ДОЛЖНЫ отправлять токены refre sh с javascript, вместо этого ДОЛЖНЫ быть делегированы любые обновления краткосрочных токенов доступа.
Теперь мой вопрос заключается в том, что если приложение A утечет мой токен доступа, так что любое приложение B может использовать этот токен доступа для получения моего ресурса, а это не то, что мне нужно.
Вот почему вы должны использовать подход Refre sh Tokens, который я упоминал ранее, потому что вы ограничиваете их доступ количеством времени, оставшимся в токене доступа, и именно поэтому я сказал, что недолговечный токены доступа должны быть в диапазоне минут.
Я хочу, чтобы только приложение A могло получить доступ к моему ресурсу, а не приложение B.
Я скажу вам жестокую правду ... это невозможно на 100%, особенно для веб-приложений, где вы можете просто нажать F12, чтобы получить доступ к консоли инструментов разработчика и найти маркер доступа, или если вы предпочитаете щелкнуть правой кнопкой мыши на странице и выбрать view source.
Мобильные приложения на первый взгляд кажутся более безопасными, потому что они поставляются в виде двоичного файла, и, следовательно, вы ожидаете, что его сложно будет реконструировать? Неправильно, это действительно легко с множеством инструментов с открытым исходным кодом, которые мы можем использовать для обратного проектирования их, и я предпочитаю MobSF :
Mobile Security Framework (MobSF) представляет собой автоматизированное универсальное мобильное приложение (Android / iOS / Windows) для тестирования пера, анализа вредоносных программ и оценки безопасности, способное выполнять анализ stati c и динамического c.
Поэтому, если вы не можете найти токены доступа с помощью анализа stati c, вы можете прибегнуть к динамическому анализу c с помощью инструментов с открытым исходным кодом, например Frida :
Внедрение собственных сценариев в процессы черного ящика. Подключите любую функцию, следите за крипто-API или отслеживайте частный код приложения, исходный код не требуется. Отредактируйте, нажмите Сохранить и мгновенно увидите результаты. Все без шагов компиляции или перезапусков программы.
И если этого недостаточно, вы также выполняете атаку «Человек посередине» (MitM) с помощью других инструментов с открытым исходным кодом, таких как mitmproxy :
Интерактивный прокси-сервер HTTP с поддержкой TLS для тестировщиков проникновения и разработчиков программного обеспечения.
Таким образом, кража токена доступа для мобильного приложения не так проста, как в веб-приложении, но это не так сложно к.
ВОЗМОЖНЫЕ РЕШЕНИЯ
Как мы доверяем приложению и даем ему мой токен доступа?
Я не знаю, является ли ваше приложение веб-или мобильным, поэтому я покажу вам возможные решения для обоих.
Прежде чем я упомяну о возможных решениях, мне нужно сначала выяснить обычное заблуждение среди разработчиков относительно кто против что получает доступ к бэкэнду. Это подробно обсуждается в этой статье , где мы можем прочитать:
what - это то, что делает запрос к серверу API. Действительно ли это подлинный экземпляр вашего мобильного приложения, или это бот, автоматизированный скрипт или злоумышленник, который вручную ковыряется в вашем сервере API с помощью такого инструмента, как Postman?
who пользователь мобильного приложения, которое мы можем аутентифицировать, авторизовать и идентифицировать несколькими способами, например, используя OpenID Connect или потоки OAUTH2.
Если у вас все еще есть сомнения, пожалуйста, go и прочитайте раздел связанная статья, которая также включает в себя графику c, чтобы помочь в понимании этого. Эта статья относится к мобильному приложению, но для понимания разницы между что и , кто обращается к бэкэнду, ссылки на mobile app можно заменить на web app .
Для веб-приложений
Если ваш вариант использования является веб-приложением, самое доступное решение, чтобы попытаться уменьшить кто против , к чему обращается ваш бэкэнд использует:
Google Recaptcha V3 :
reCAPTCHA - это бесплатный сервис, который защищает ваш сайт от спама и злоупотреблений. Он использует передовые методы анализа рисков, чтобы отличать людей и ботов от других.
Используется Аналитика поведения пользователя (UBA) , чтобы сообщить appart кто и что обращается к вашему бэкэнду.
Аналитика поведения пользователей (UBA) в соответствии с определением Gartner - это процесс кибербезопасности, связанный с обнаружением внутренних угроз, целевых атак и финансового мошенничества. Решения UBA рассматривают модели поведения людей, а затем применяют алгоритмы и статистический анализ для выявления значимых аномалий из этих моделей - аномалий, которые указывают на потенциальные угрозы. [1] Вместо отслеживания устройств или событий безопасности, UBA отслеживает пользователей системы.
Это склонно к ложным срабатываниям, поэтому вам нужно быть осторожным, принимая решение принять или нет запрос на основе оценка, возвращаемая reCPATCHA V3 для каждого запроса:
reCAPTCHA v3 возвращает оценку для каждого запроса без трений пользователя. Оценка основана на взаимодействиях с вашим сайтом и позволяет вам предпринять соответствующие действия для вашего сайта.
Для мобильных приложений
Как вы видели из множества инструментов, доступных для реверсирования Создавайте мобильные приложения, статически или динамически, токен доступа для идентификации вашего пользователя не так уж безопасен, плюс он только определяет who в запросе, а не что делает .
Решение, которое может позволить вашему бэкэнду быть уверенным, что запрос действительно поступил от того же самого мобильного приложения, которое было загружено в Google Play или Apple store, представляет собой решение для аттестации мобильных приложений, которое представляет собой концепцию, которая вводит новый способ обеспечения безопасности для вашего мобильного приложения и серверной части в единой форме.
Обычные подходы ориентированы на многое на стороне мобильного приложения, но в первую очередь данные, которые вы хотите защитить, находятся на вашем бэкэнд-сервере, и именно здесь вы хотите иметь способ узнать, что делает запрос действительно тонким, как вы ожидаете, ваше подлинное мобильное приложение.
Концепция аттестации мобильных приложений описана в этом разделе другой статьи, которую я написал, откуда я процитирую следующий текст:
Роль службы аттестации мобильных приложений состоит в том, чтобы аутентифицировать то, что отправляет запросы, таким образом, только отвечая на запросы, поступающие из подлинных экземпляров мобильного приложения, и отклоняя все другие запросы из неавторизованных источников.
Для того, чтобы узнать то, что отправляет запросы на сервер API, служба аттестации мобильных приложений во время выполнения идентифицирует с высокой степенью уверенности в том, что ваше мобильное приложение присутствует, не было взломано / переупаковано, не запущено на корневом устройстве, не был зацеплен инструментарием (Frida, xPposed, Cydia и др. c.) и не является объектом "Человек в средней атаке" (MitM). Это достигается путем запуска SDK в фоновом режиме, который будет взаимодействовать со службой, работающей в облаке, для подтверждения целостности мобильного приложения и устройства, на котором оно работает.
При успешном подтверждении целостности мобильного приложения выдан кратковременный токен JWT, подписанный секретом, который известен только облачному API-серверу и службе аттестации мобильных приложений в облаке. В случае неудачной аттестации токен JWT подписывается с неверным секретом. Поскольку секрет, используемый службой аттестации мобильных приложений, не известен мобильному приложению, невозможно выполнить обратный инжиниринг его во время выполнения, даже если приложение было взломано, запущено на корневом устройстве или обменивается данными через соединение это цель атаки MitM.
Мобильное приложение должно отправлять токен JWT в заголовке каждого запроса API. Это позволяет серверу API обслуживать запросы только в том случае, если он может проверить, что токен JWT был подписан общим секретным ключом и срок его действия не истек. Все остальные запросы будут отклонены. Другими словами, действительный токен JWT сообщает серверу API, что запрос выполняет подлинное мобильное приложение, загруженное в магазин Google или Apple, в то время как недействительный или отсутствующий токен JWT означает, что то, что делает запрос, не авторизовано для этого. потому что это может быть бот, переупакованное приложение или злоумышленник, выполняющий атаку MitM.
Таким образом, этот подход позволит вашему внутреннему серверу доверять с очень высокой степенью уверенности в том, что запрос поступает действительно из того же самого мобильного приложения, которое вы загрузили в Google Play и Apple store, при условии, что токен JWT имеет действительную подпись и время истечения срока действия, а также отклоняет все другие запросы как ненадежные.
GOING THE EXTRA MILE
К концу sh мой ответ я не могу удержаться, чтобы рекомендовать вам отличную работу фонда OW ASP, потому что из-за их отличной работы и для меня ни одно решение по безопасности для Интернета и мобильных устройств не обходится без изучения их руководств :
Тестирование веб-безопасности Руководство :
Руководство по тестированию веб-безопасности OW ASP включает в себя инфраструктуру тестирования на проникновение «передовой опыт», которую пользователи могут внедрить в своих организациях, и руководство по тестированию на проникновение «низкого уровня», которое описывает методы тестирования наиболее распространенных проблем безопасности веб-приложений и веб-служб.
Руководство по тестированию безопасности мобильных устройств :
Руководство по тестированию безопасности мобильных устройств ( MSTG) - это всеобъемлющее руководство по разработке, тестированию и реверс-инжинирингу безопасности мобильных приложений.