Разница между ВОЗ и ЧТО получает доступ к серверу API
Прежде чем мы сможем понять варианты решения вашей проблемы, я хотел бы прояснить распространенное заблуждение среди разработчиков относительно ВОЗ против ЧТО обращается к серверу API.
Чтобы лучше понять различия между WHO и ЧТО , обращающимися к серверу API, давайтеиспользуйте эту картинку:
Предполагаемый канал связи представляет собой мобильное приложение, которое используется, как вы ожидали, легальным пользователем без каких-либо злонамеренных намерений, используя нетронутую версию мобильного приложения.и напрямую взаимодействует с сервером API, не подвергаясь атаке «человек посередине».
Фактический канал может представлять несколько различных сценариев, например, законный пользователь со злонамеренными намерениями, который может использовать переупакованную версию мобильного приложения,хакер использует подлинную версию мобильного приложения, а человек в серединеdle атакует его, чтобы понять, как осуществляется связь между мобильным приложением и сервером API, чтобы иметь возможность автоматизировать атаки на ваш API.Возможны многие другие сценарии, но мы не будем перечислять здесь каждый.
Я надеюсь, что к настоящему времени у вас уже может быть подсказка, почему WHO и WHAT не одно и то же, но если нет, то это станет ясно через мгновение.
WHO - это пользователь мобильного приложения, которое мы можем аутентифицировать, авторизовывать и идентифицировать несколькими способами, напримериспользуя OpenID Connect или потоки OAUTH2.
OAUTH
Обычно OAuth предоставляет клиентам «безопасный делегированный доступ» к ресурсам сервера от имени владельца ресурса,Он определяет процесс для владельцев ресурсов, чтобы разрешить сторонний доступ к своим ресурсам сервера без совместного использования своих учетных данных.Разработанный специально для работы с протоколом гипертекстовой передачи (HTTP), OAuth, по сути, позволяет выдавать маркеры доступа сторонним клиентам с помощью сервера авторизации с разрешения владельца ресурса.Затем третья сторона использует токен доступа для доступа к защищенным ресурсам, размещенным на сервере ресурсов.
OpenID Connect
OpenID Connect 1.0 представляет собой простой слой идентификации поверхпротокол OAuth 2.0.Это позволяет клиентам проверять подлинность конечного пользователя на основе аутентификации, выполняемой сервером авторизации, а также получать базовую информацию о профиле конечного пользователя взаимодействующим и REST-подобным образом.
Хотя аутентификация пользователя может сообщить серверу API, что WHO использует API, она не может гарантировать, что запросы исходили из ожидаемой ЧТО исходной версии мобильного приложения..
Теперь нам нужен способ определить ЧТО вызывает API-сервер, и здесь все становится сложнее, чем может подумать большинство разработчиков. WHAT - это то, что делает запрос к серверу API.Действительно ли это подлинный экземпляр мобильного приложения, или это бот, автоматизированный скрипт или злоумышленник, который вручную ковыряется на сервере API, используя такой инструмент, как Postman?
К вашему удивлению, вы можете обнаружитьчто это может быть один из законных пользователей, использующих переупакованную версию мобильного приложения или автоматизированный сценарий, который пытается геймифицировать и воспользоваться службой, предоставляемой приложением.
Ну, чтобы определить ЧТО , разработчики, как правило, прибегают к API-ключу, который обычно они жестко кодируют в коде своего мобильного приложения.Некоторые разработчики делают все возможное и вычисляют ключ во время выполнения в мобильном приложении, таким образом, он становится секретом времени выполнения в отличие от прежнего подхода, когда в код встроен статический секрет.
Приведенная выше статья была взята из статьи, которую я написал, под названием ПОЧЕМУ ВАШЕМУ МОБИЛЬНОМУ ПРИЛОЖЕНИЮ НУЖЕН КЛЮЧ API? , и которую вы можете прочитать полностью здесь , то есть первая статья в серии статей о ключах API.
Ваш вопрос
Так что мне интересно, как я могу убедиться, что операции CRUD для моего успокоительного API принимаются только моим собственным приложением, а не посторонними?
Защита и блокировка сервера API для вашего собственного приложения - непростая задача, поскольку любые секреты, используемые для идентификации WHO или WHAT , относительно легко взломать злоумышленнику. , Вы можете прочитать статью Как извлечь ключ API из мобильного приложения с помощью статического двоичного анализа , где я демонстрирую, как их можно извлечь с помощью нескольких инструментов с открытым исходным кодом, например, с помощью Mobile. Security Framework , или вы можете прочитать эту другую статью Украсть этот ключ API вместе с атакующим человеком в середине , который использует инструмент с открытым исходным кодом MiTM Proxy для запуска человека в средняя атака для извлечения ключа API.
К настоящему времени вы, возможно, уже поняли, что очень трудно защитить сервер API от злоупотреблений со стороны злоумышленников, потому что после того, как они извлекли секреты для идентификации WHO и WHAT делает запрос, они могут использовать интересующий вас инструмент, Почтальон или любой другой для атаки на ваш API-сервер, и притворяться легитами WHO и WHAT .
Возможно, вы сейчас спрашиваете ... Как я могу защитить свой сервер API?
Защита API-сервера
Рекомендуется, чтобы мобильное приложение или веб-приложение взаимодействовали только с сервером API, находящимся под вашим контролем, и любой доступ к сторонним службам API должен осуществляться с того же сервера API, которым вы управляете. Таким образом, вы ограничите поверхность атаки только одним местом, где вы будете использовать столько уровней защиты, сколько стоит то, что вы защищаете.
Вы можете начать с reCaptcha V3 , за которым следует Брандмауэр веб-приложений (WAF) и, наконец, если вы можете себе это позволить Аналитика поведения пользователя (UBA) решение.
Google reCAPTCHA V3 :
reCAPTCHA - это бесплатный сервис, который защищает ваш сайт от спама и злоупотреблений. reCAPTCHA использует усовершенствованный механизм анализа рисков и адаптивные задачи, чтобы автоматизированное программное обеспечение не использовалось для злоупотреблений на вашем сайте. Он делает это, позволяя вашим действительным пользователям легко проходить через них.
... помогает обнаруживать оскорбительный трафик на вашем сайте без каких-либо проблем со стороны пользователя. Он возвращает оценку, основанную на взаимодействиях с вашим веб-сайтом, и предоставляет вам больше возможностей для принятия соответствующих действий.
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, например, из POSTMAN.
Ну, почтальон по умолчанию использует пользовательский заголовок http, поэтому легко блокировать запросы от него, но это будет работать, только если пользователь не отключит эту функцию Postamn и злоумышленники всегда отключат их, поэтому эта мера не будет быть очень эффективным, и если Почтальон не единственный инструмент, вам нужно быть более изощренным в своей защите, чем этот.
Как сделать так, чтобы люди, которые копируют мое приложение, могли выполнять операции CRUD для моего API?
Я думаю, вы хотите иметь в виду, что только люди, использующие ваше приложение, могут выполнять операции CRUD.
В конце концов, решение, которое будет использоваться для защиты вашего API-сервера, должно быть выбрано в соответствии со значением того, что вы пытаетесь защитить, и юридическими требованиями к данным такого типа, такими как нормативы GDPR в Европе.
Поэтому я рекомендую вам внедрить решение для аттестации мобильных приложений, потому что это положительная модель, которая может решить ваши проблемы.