Предположим, я разрабатываю мобильное приложение, которое выполняет звонки на сервер API. Сервер API защищен ключом API.
Давайте сначала разберемся с распространенным заблуждением среди разработчиков по поводу 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.
ВАША ПРОБЛЕМА
Таким образом, ваша проблема не может быть решена с помощью сервера аутентификации / авторизации, независимо от того, использует ли он Oauth, OpenID или любой другой тип аутентификации, потому что, как вы, возможно, уже поняли, этот сервер будет идентифицировать только WHO обращается к вашему серверу API, а не ЧТО обращается к нему.
Просто чтобы прояснить, я не говорю, что этот подход не должен использоваться, фактически использование Oauth2 / OpenID - это лучший подход для определения того, WHO обращается к серверу API.
К настоящему времени вы можете думать о том, как вы решите свою проблему:
Я не могу жестко закодировать ключ API внутри мобильного приложения, поскольку его можно украсть.
Ну, вы купили себе головную боль, которую ни один врач или лекарство не может устранить.
Это правда, что если вы прячете какой-либо секрет в мобильном приложении, то он может быть затем переработан. В этой статье я писал об одном из наиболее эффективных способов скрыть ключ API в мобильном приложении, используя JNI / NDK , но в то же время я также писал о том, как можно перепроектировать это:
Пришло время искать более продвинутую технику, чтобы скрыть ключ API таким способом, который будет очень трудно восстановить из APK, и для этого мы будем использовать собственный код C ++ для хранения ключа API, путем используя интерфейс JNI, который использует NDK под капотом.
Прежде чем я начал отвечать на ваш вопрос, я закончил черновик для моей следующей статьи, которая будет о том, как выполнить атаку Человек в середине, чтобы украсть ключ API, и вы сможете прочитать что-то вокруг это:
Хотя мы можем использовать передовые методы, такие как JNI / NDK, чтобы скрыть ключ api в коде мобильного приложения, это не помешает кому-либо выполнить MITM-атаку для кражи ключа api. На самом деле атака MITM проста до такой степени, что может быть достигнута даже не разработчиками.
Я говорю вам, что нет никакой надежды на защиту сервера API от ЧТО получает к нему доступ? Ну нет, я не ...
ВОЗМОЖНОЕ РЕШЕНИЕ
Как я могу защитить ключ API?
Мобильное приложение должно взаимодействовать только с сервером API, который находится под вашим контролем, и любой доступ к службам API третьей части должен осуществляться с того же сервера API, которым вы управляете.
Таким образом, вы ограничиваете поверхность атаки только одним местом, где вы будете использовать столько уровней защиты, сколько стоит то, что вы защищаете.
В зависимости от значения ключа API, который вы пытаетесь защитить, вы можете использовать брандмауэр веб-приложений (WAF) и, если вы можете себе это позволить, Analytics поведения пользователя (UBA) решение.
WAF - Брандмауэр веб-приложений :
Брандмауэр веб-приложения (или WAF) фильтрует, отслеживает и блокирует HTTP-трафик в веб-приложение и из него. WAF отличается от обычного брандмауэра тем, что WAF может фильтровать содержимое определенных веб-приложений, в то время как обычные брандмауэры служат в качестве шлюза безопасности между серверами. Проверяя HTTP-трафик, он может предотвратить атаки, связанные с недостатками безопасности веб-приложений, такими как внедрение SQL, межсайтовый скриптинг (XSS), включение файлов и неправильная настройка безопасности.
UBA - Аналитика поведения пользователя :
Анализ поведения пользователей (UBA), как определено Gartner, представляет собой процесс кибербезопасности, связанный с обнаружением внутренних угроз, целевых атак и финансового мошенничества.Решения UBA рассматривают модели поведения людей, а затем применяют алгоритмы и статистический анализ для выявления значимых аномалий из этих моделей - аномалий, которые указывают на потенциальные угрозы.Вместо отслеживания устройств или событий безопасности, UBA отслеживает пользователей системы.Платформы больших данных, такие как Apache Hadoop, расширяют функциональность UBA, позволяя им анализировать данные объемом в петабайты для обнаружения внутренних угроз и расширенных постоянных угроз.
Все эти решения работают на основе модели отрицательной идентификации, другимислова, которые они стараются отличить плохое от хорошего, определяя, что плохо, а не что хорошо, поэтому они склонны к ложным срабатываниям, несмотря на передовые технологии, используемые некоторыми из них, такие как машинное обучение и искусственный интеллект.
Таким образом, вы можете чаще испытывать необходимость ослабить блокировку доступа к API-серверу, чтобы не влиять на хороших пользователей.Это также означает, что этим решениям требуется постоянный мониторинг для проверки того, что ложные срабатывания не блокируют ваших законных пользователей и в то же время они должным образом защищают неавторизованных пользователей.
В отношении API, обслуживающих мобильные приложения, положительная идентификацияМодель можно использовать с помощью решения для аттестации мобильных приложений, которое гарантирует серверу API, что запросы можно доверять без возможности ложных срабатываний.
Аттестация мобильных приложений
РольСлужба аттестации мобильных приложений должна гарантировать во время выполнения, что ваше мобильное приложение не было взломано или не запущено на корневом устройстве, запустив SDK в фоновом режиме, который будет взаимодействовать со службой, работающей в облаке, чтобы подтвердить целостность мобильного устройства.приложение и устройство работают.
При успешной проверке целостности мобильного приложения выдается кратковременный токен JWT, который подписывается с секретом, что только сервер API и Аттестат мобильного приложенияИонные службы в облаке знают.В случае сбоя при аттестации мобильного приложения токен JWT подписывается секретом, которого сервер API не знает.
Теперь приложение должно отправлять при каждом вызове API токен JWT в заголовках запроса.,Это позволит серверу API обслуживать запросы только тогда, когда он может проверить подпись и время истечения срока действия в токене JWT и отклонить их, если он не прошел проверку.
Как только секрет, используемый службой аттестации мобильных приложений, не являетсяизвестное мобильному приложению, невозможно выполнить его реинжиниринг во время выполнения, даже когда приложение подделано, работает на корневом устройстве или осуществляет связь по соединению, которое является целью «человека в средней атаке».
Служба аттестации мобильных приложений уже существует в качестве решения SAAS на Approov (я работаю здесь), который предоставляет SDK для нескольких платформ, включая iOS, Android, React Native и другие.Для интеграции также потребуется небольшая проверка кода сервера API для проверки токена JWT, выпущенного облачной службой.Эта проверка необходима для того, чтобы сервер API мог решать, какие запросы обслуживать, а какие отклонять.
ЗАКЛЮЧЕНИЕ
В конце концов решение, которое нужно использовать для защиты вашего сервера APIдолжны быть выбраны в соответствии со значением того, что вы пытаетесь защитить, и с юридическими требованиями для этого типа данных, такими как нормативы GDPR в Европе.
Таким образом, использование ключей API может звучать как запирание двери вашегоДомой и оставьте ключ под ковриком, но не пользуйтесь им - все равно, что оставить машину на стоянке с закрытой дверью, но ключ в замке зажигания.