КТО и ЧТО обращается к серверу API
Я хотел бы начать с разъяснения различия между ЧТО и ВОЗ обращается к серверу API.
WHO является пользователем мобильного приложения, которое можно аутентифицировать, авторизовать и идентифицировать несколькими способами, например, используя потоки OpenID или OAUTH2.
Теперь вам нужен способ определить, ЧТО вызывает ваш API-сервер, и здесь все становится сложнее, чем может подумать большинство разработчиков. ЧТО - это то, что делает запрос к серверу API, действительно ли это ваше подлинное мобильное приложение, или это робот, автоматизированный скрипт или злоумышленник, вручную копающийся в вашем сервере API с помощью такого инструмента, как Postman?
Хорошо, чтобы определить ЧТО разработчики, как правило, прибегают к API-ключу, который обычно они жестко кодируют в коде своего мобильного приложения, а некоторые прилагают дополнительные усилия и вычисляют его во время выполнения в мобильное приложение, таким образом, становится динамическим секретом в отличие от прежнего подхода, который представляет собой статический секрет, встроенный в код.
Проблема с API-ключами
У меня уже есть проверка для обработки запроса, если только они отправили действительный ключ API. Но на веб-сайте и в приложении я использую мастер-ключ API, который имеет доступ ко всем.
Я полагаю, что это можно увидеть в исходном файле на веб-сайте, и его можно изменить в мобильном приложении.
В веб-приложении нам нужно только проверить исходный код с помощью инструментов разработчика браузера или щелкнуть правой кнопкой мыши на исходной странице просмотра и найти ключ API.
В мобильном приложении мы можем начать с быстрого шпиона в двоичном файле с помощью команды string в linux:
$ strings -aw app-debug.apk | grep -C 1 '_API_' -
ic_launcher_round
GRADLE_API_KEY
GRADLE_ENV_API_KEY
abc_action_bar_home_description
Для более полного и подробного сканирования MobSF поможет вам перепроектировать двоичный файл мобильного приложения, чтобы извлечь ключ API и перечислить другие векторы атаки.
Mobile Security Framework - это автоматизированная универсальная платформа для ручного тестирования мобильных приложений (Android / iOS / Windows), позволяющая выполнять статический анализ, динамический анализ, анализ вредоносных программ и тестирование веб-API.
Таким образом, все, что работает на стороне клиента и нуждается в некотором секрете для доступа к API, может быть использовано по-разному, и вы можете узнать больше о этой серии статей о технологиях безопасности Mobile API. В этих статьях вы узнаете, как можно использовать ключи API, токены доступа пользователей, HMAC и TLS Pinning для защиты API и как их можно обойти.
Защита API-сервера
но как я могу получить к нему доступ на моих компонентах ReactJS?
Извините, но у меня нет знаний, чтобы помочь вам, но продолжайте читать, чтобы понять, что можно сделать для защиты вашего API-сервера.
Возможное решение, которое я имею для веб-сайта, состоит в том, чтобы сделать процесс на сервере вместо использования AJAX ...?
Для мобильного приложения, я должен переключиться на использование Swift / Java и сделать запрос там вместо выборки?
Мобильное приложение или веб-приложение должны взаимодействовать только с сервером 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-сервера, должно быть выбрано в соответствии со значением того, что вы пытаетесь защитить, и с юридическими требованиями для этого типа данных, такими как нормативы GDPR в Европе.
Таким образом, использование ключей API может звучать как запирание двери вашего дома и оставлять ключ под ковриком, но не использовать их - это все равно, что оставить машину на стоянке с закрытой дверью, но ключ в замке зажигания.