Прежде чем ответить на ваш вопрос, я считаю важным, чтобы сначала мы выяснили распространенное среди разработчиков заблуждение относительно WHO и WHAT доступа к API.
РАЗНИЦА МЕЖДУ КТО И ЧТО ОБЩАЕТСЯ С ВАШИМ СЕРВЕРОМ API
Чтобы лучше понять разницу между WHO и WHAT , обращающимися к вашему мобильному приложению, давайте воспользуемся этой картинкой:
Предполагаемый канал связи представляет ваш мобильный телефон, который, как вы и ожидали, используется законным пользователем без каких-либо злонамеренных намерений, использует нетронутую версию вашего мобильного приложения и напрямую взаимодействует с вашим сервером API, не подвергаясь атаке человека посередине.
Фактический канал может представлять несколько различных сценариев, например, законный пользователь со злонамеренными намерениями, который может использовать переупакованную версию вашего мобильного приложения, хакер, использующий подлинную версию вашего мобильного приложения, в то время как посредник атакует его, чтобы понять как осуществляется связь между мобильным приложением и сервером API, чтобы иметь возможность автоматизировать атаки на ваш API. Возможны многие другие сценарии, но мы не будем перечислять здесь каждый.
Я надеюсь, что к настоящему времени у вас уже может быть подсказка, почему WHO и WHAT не совпадают, но если нет, то это станет ясно через мгновение.
WHO является пользователем мобильного приложения, которое мы можем аутентифицировать, авторизовывать и идентифицировать несколькими способами, например, используя OpenID Connect или потоки OAUTH2.
OAuth
Как правило, OAuth предоставляет клиентам «безопасный делегированный доступ» к ресурсам сервера от имени владельца ресурса. Он определяет процесс для владельцев ресурсов, чтобы разрешить сторонний доступ к своим ресурсам сервера без совместного использования своих учетных данных. Разработанный специально для работы с протоколом гипертекстовой передачи (HTTP), OAuth, по сути, позволяет выдавать маркеры доступа сторонним клиентам с помощью сервера авторизации с разрешения владельца ресурса. Затем третья сторона использует токен доступа для доступа к защищенным ресурсам, размещенным на сервере ресурсов.
OpenID Connect
OpenID Connect 1.0 - это простой идентификационный уровень поверх протокола OAuth 2.0. Это позволяет клиентам проверять подлинность конечного пользователя на основе аутентификации, выполняемой сервером авторизации, а также получать базовую информацию о профиле конечного пользователя взаимодействующим и REST-подобным образом.
Хотя аутентификация пользователя может сообщить вашему API-серверу, что ВОЗ использует API, она не может гарантировать, что ваши запросы поступили из ЧТО вашего мобильного приложения.
Теперь нам нужен способ определить, ЧТО вызывает ваш API-сервер, и здесь все становится сложнее, чем может показаться большинству разработчиков. WHAT - это то, что делает запрос к серверу API. Действительно ли это подлинный экземпляр вашего мобильного приложения, или это робот, автоматизированный скрипт или злоумышленник, вручную копающийся в вашем API-сервере с помощью такого инструмента, как Postman?
К вашему удивлению, вы можете обнаружить, что это может быть один из ваших законных пользователей, использующий переупакованную версию вашего мобильного приложения или автоматизированный скрипт, пытающийся геймифицировать и воспользоваться вашим сервисом.
Ну, чтобы определить ЧТО , разработчики склонны прибегать к API-ключу, который обычно они жестко кодируют в коде своего мобильного приложения. Некоторые разработчики делают все возможное и вычисляют ключ во время выполнения в мобильном приложении, таким образом, он становится секретом времени выполнения в отличие от прежнего подхода, когда в код встроен статический секрет.
Приведенная выше статья была взята из статьи, которую я написал, под названием ПОЧЕМУ ВАШЕМУ МОБИЛЬНОМУ ПРИЛОЖЕНИЮ НУЖЕН КЛЮЧ API? , и которую вы можете прочитать полностью здесь , то естьпервая статья в серии статей о ключах API.
ВАШИ ВОПРОСЫ
У меня настроена аутентификация для пользователей, которые вошли в систему только с возможностью доступа к API,тем не менее, как я могу запретить им входить в систему из любого места?
Если под logging in from anywhere вы подразумеваете любое физическое местоположение, то вы можете использовать блокировку по IP-адресу, как уже предложено @hanshenrik, ноесли вы имеете в виду блокирование входа в систему из других приложений, для которых вы не выпустили ключи API, то у вас есть очень сложная проблема, которую нужно решить, что приводит к вашему первому вопросу:
Я настроил API с аутентификацией, но я хочу разрешить доступ к нему только определенным приложениям и веб-сайтам.Что мне делать?
Это будет зависеть, если ЧТО обращается к API, является веб-приложением или мобильным приложением.
Веб-приложение
В веб-приложении нам нужно только проверить исходный код с помощью инструментов разработчика браузера или щелкнуть правой кнопкой мыши на источнике страницы просмотра и найти ключ API, а затем использовать его в любом инструменте, например, в Postman или в любом виде автоматизации, который мыхочу, просто реплицируя вызовы, как мы видели, на вкладке сети браузера.
Для API, обслуживающего веб-приложение, вы можете использовать несколько плотных уровней, начиная с reCaptcha V3 , затем Брандмауэр веб-приложений (WAF) и, наконец, если вы можете себе это позволить, решение Analytics поведения пользователей (UBA).
Google reCAPTCHAV3 :
reCAPTCHA - это бесплатный сервис, который защищает ваш сайт от спама и злоупотреблений.reCAPTCHA использует усовершенствованный механизм анализа рисков и адаптивные задачи, чтобы автоматизированное программное обеспечение не использовалось для злоупотреблений на вашем сайте.Он делает это, позволяя вашим действительным пользователям легко проходить через них.
... помогает вам обнаруживать оскорбительный трафик на вашем сайте без каких-либо проблем со стороны пользователей.Он возвращает оценку, основанную на взаимодействиях с вашим веб-сайтом, и предоставляет вам большую гибкость для принятия соответствующих действий.
WAF - брандмауэр веб-приложений :
Брандмауэр веб-приложений (или WAF) фильтрует, отслеживает и блокирует HTTP-трафик в веб-приложение и из него.WAF отличается от обычного брандмауэра тем, что WAF может фильтровать содержимое определенных веб-приложений, в то время как обычные брандмауэры служат в качестве шлюза безопасности между серверами.Проверяя HTTP-трафик, он может предотвратить атаки, связанные с недостатками безопасности веб-приложений, такими как внедрение SQL, межсайтовый скриптинг (XSS), включение файлов и неправильная конфигурация безопасности.
UBA -Аналитика поведения пользователя :
Аналитика поведения пользователя (UBA) в соответствии с определением Gartner - это процесс кибербезопасности, связанный с обнаружением внутренних угроз, целевых атак и финансового мошенничества.Решения UBA рассматривают модели поведения людей, а затем применяют алгоритмы и статистический анализ для выявления значимых аномалий из этих моделей - аномалий, которые указывают на потенциальные угрозы.Вместо отслеживания устройств или событий безопасности, UBA отслеживает пользователей системы.Платформы больших данных, такие как Apache Hadoop, расширяют функциональность UBA, позволяя им анализировать данные объемом в петабайты для обнаружения внутренних угроз и расширенных постоянных угроз.
Все эти решения работают на основе модели отрицательной идентификации, другимислова, которые они изо всех сил стараются отличить плохое от хорошего, идентифицируя ЧТО плохо, а не ЧТО хорошо, поэтому они склонны к ложным срабатываниям, несмотря на передовые технологии, используемыенекоторые из них, такие как машинное обучение и искусственный интеллект.
Таким образом, вам, скорее всего, придется расслабиться, блокируя доступ к API-серверу, чтобы не влиять на хороших пользователей. Это также означает, что этим решениям требуется постоянный мониторинг для проверки того, что ложные срабатывания не блокируют ваших законных пользователей и в то же время они должным образом защищают неавторизованных пользователей.
Мобильное приложение
Из вашего ответа на комментарий:
А как насчет мобильных приложений?
Некоторые могут подумать, что после выпуска мобильного приложения в двоичном формате их ключ API будет безопасным, но оказывается, что это не так, и извлечение его из двоичного файла иногда почти так же просто, как извлечение его из Интернета. применение.
Обратный инжиниринг мобильного приложения упрощается благодаря множеству инструментов с открытым исходным кодом, таких как Mobile Security Framework (MobSF), Frida, XPposed, MitmProxy и многим другим, но, как вы можете видеть в этой статье , это можно сделать с помощью MobSF или с помощью утилиты strings, установленной в обычном дистрибутиве Linux.
Mobile Security Framework
Mobile Security Framework - это автоматизированная универсальная платформа для ручного тестирования мобильных приложений (Android / iOS / Windows), позволяющая выполнять статический анализ, динамический анализ, анализ вредоносных программ и тестирование веб-API.
Фрида
Внедрение собственных сценариев в процессы черного ящика. Подключите любую функцию, следите за крипто-API или отслеживайте частный код приложения, исходный код не требуется. Отредактируйте, нажмите «Сохранить» и мгновенно увидите результаты. Все без шагов компиляции или перезапуска программы.
Экспоузд
Xposed - это фреймворк для модулей, который может изменять поведение системы и приложений, не касаясь каких-либо APK. Это здорово, потому что это означает, что модули могут работать для разных версий и даже ПЗУ без каких-либо изменений (если исходный код не был слишком изменен). Это также легко отменить.
MiTM Proxy
Интерактивный перехватывающий HTTP-прокси с поддержкой TLS для тестеров на проникновение и разработчиков программного обеспечения.
В отношении API, обслуживающих мобильные приложения, модель положительной идентификации можно использовать с помощью решения для аттестации мобильных приложений, которое гарантирует серверу API, что ЧТО делает запросы, можно доверять, без возможности ложных срабатываний .
Аттестация мобильного приложения
Роль службы аттестации мобильных приложений заключается в том, чтобы во время выполнения гарантировать, что ваше мобильное приложение не было взломано или не запущено на корневом устройстве, запустив SDK в фоновом режиме, который будет взаимодействовать со службой, работающей в облаке. чтобы подтвердить целостность мобильного приложения и работающего устройства.
При успешной аттестации целостности мобильного приложения выдается кратковременный токен JWT, который подписывается с секретом, о котором знают только сервер API и служба аттестации мобильных приложений в облаке. В случае сбоя при аттестации мобильного приложения токен JWT подписывается секретом, которого сервер API не знает.
Теперь приложение должно отправлять при каждом вызове API токен JWT в заголовках запроса. Это позволит серверу API обслуживать запросы только в том случае, если он может проверить подпись и время истечения срока действия в маркере JWT и отклонить их, если он не прошел проверку.
Поскольку секретный ключ, используемый службой аттестации мобильных приложений, не известен мобильному приложению, невозможно восстановить его во время выполнения, даже когда приложение подделано, работает на корневом устройстве или осуществляет связь через соединение, которое является целью человека в средней атаке.
Служба аттестации мобильных приложений уже существует в качестве решения SAAS на Approov (я работаю здесь), который предоставляет SDK для нескольких платформ, включая iOS, Android, React Native и другие. Для интеграции также потребуется небольшая проверка кода сервера API для проверки токена JWT, выпущенного облачной службой. Эта проверка необходима для того, чтобы сервер API мог решать, какие запросы обслуживать, а какие отклонять.
ЗАКЛЮЧЕНИЕ
В конце концов, решение, которое будет использоваться для защиты вашего API-сервера, должно быть выбрано в соответствии со значением того, что вы пытаетесь защитить, и с юридическими требованиями для этого типа данных, такими как нормативы GDPR в Европе.
Таким образом, использование API-ключей может звучать как запирание двери вашего дома и оставлять ключ под ковриком, но не использовать их - все равно, что оставить машину на стоянке с закрытой дверью, но ключ в замке зажигания.