КТО И ЧТО ДОСТУПАЕТ К СЕРВЕРУ API
Прежде чем ответить на ваш вопрос, я хотел бы прояснить различие между WHO и ЧТО получает доступ к APIсервер.
WHO является пользователем мобильного приложения, которое можно аутентифицировать, авторизовывать и идентифицировать несколькими способами, например, используя потоки OpenID или OAUTH2.
Теперь вынужен способ определить, ЧТО вызывает ваш API-сервер, и здесь все становится сложнее, чем может подумать большинство разработчиков. ЧТО - это то, что делает запрос к серверу API, действительно ли это ваше подлинное мобильное приложение, или это робот, автоматизированный скрипт или злоумышленник, вручную копающийся в вашем сервере API с помощью такого инструмента, как Postman?
Хорошо, чтобы идентифицировать ЧТО разработчики склонны прибегать к API-ключу, который обычно они жестко кодируют в коде своего мобильного приложения, а некоторые прилагают дополнительные усилия и вычисляют его во время выполненияв мобильном приложении, таким образом, становится динамическим секретом в отличие от прежнего подхода, который представляет собой статический секрет, встроенный в код.
ПРОБЛЕМА
Скажем, у меня есть API, где пользователиможете войти через OAuth2.Какие у меня есть варианты, чтобы разрешить только доверенным приложениям взаимодействовать с частями этого API?
Вы столкнулись с очень сложной проблемой, которую нужно решить ...
Если ваш API обслуживает только мобильные устройстваприложения вы можете сохранить свою формулировку, но с момента создания API, который необходим для серверных веб-приложений, вы больше не можете применять формулировку allowing only trusted applications, и вам придется удовлетворять себя чем-то около preventing access of unauthorized applications.
Проблема с веб-приложениями заключается в том, что вам нужно только проверить исходный код веб-страницы с помощью инструментов разработчика браузера, чтобы иметь возможность извлечь любой секрет, используемый для идентификации веб-приложения, на сервер API.
С мобильным приложением некоторые разработчики ошибочно полагают, что после выпуска в двоичном виде невозможно извлечь секреты или это очень сложно ... Давайте посмотрим, как команда strings в 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
Вы можете предотвратить вышесказанное, запутав код при создании релиза, но тогда нам просто нужно использовать более сложные инструменты, такие как Mobile Security Framework (MobSF), которые используют под капотом набор других открытых исходных кодов.инструменты для декомпиляции двоичного файла и выполнения статического анализа на нем для перечисления всех векторов атак и раскрытия секретов, встроенных в код.
Mobile Security Framework
Mobile Security Framework - это автоматизированное универсальное мобильное приложение (Android / iOS / Windows) для тестирования пера.k способен выполнять статический анализ, динамический анализ, анализ вредоносных программ и тестирование веб-API.
Таким образом, все, что работает на стороне клиента и нуждается в секрете для доступа к API, может быть использовано по-разному, и выВы можете узнать больше о этой серии статей о технологиях безопасности Mobile API.В этой статье вы узнаете, как можно использовать ключи API, токены доступа пользователей, HMAC и TLS Pinning для защиты API и как их можно обойти.
ПРЕДУПРЕЖДЕНИЕ НАРУШЕНИЯ API
InДругими словами, как Facebook, Twitter и Instagram не позволяют людям просто клонировать идентификатор клиента из своих мобильных приложений и использовать их целые API, как если бы они были официальным приложением?
Я не знаю, чтоони специально используются для предотвращения злоупотребления API с помощью клонированных идентификаторов, но любой, кто хочет защитить свои API от неправомерного использования их неофициальными клиентами, будет использовать решения для брандмауэров веб-приложений (WAF) и анализа поведения пользователей (UBA), которые используют машинное обучение и искусственный интеллект.обнаруживать плохое поведение и блокировать их доступ к API.
WAF - брандмауэр веб-приложений :
Брандмауэр веб-приложений (или WAF) фильтрует, отслеживает и блокирует HTTP-трафик в веб-приложение и из него.WAF отличается от обычного брандмауэра тем, что WAF может фильтровать содержимое определенных веб-приложений, в то время как обычные брандмауэры служат в качестве шлюза безопасности между серверами.Проверяя HTTP-трафик, он может предотвратить атаки, связанные с недостатками безопасности веб-приложений, такими как внедрение SQL, межсайтовый скриптинг (XSS), включение файлов и неправильные конфигурации безопасности.
UBA -Аналитика поведения пользователя :
Аналитика поведения пользователя (UBA), как определено Gartner, представляет собой процесс кибербезопасности, связанный с обнаружением внутренних угроз, целевых атак и финансового мошенничества.Решения UBA рассматривают модели поведения людей, а затем применяют алгоритмы и статистический анализ для выявления значимых аномалий из этих моделей - аномалий, которые указывают на потенциальные угрозы.Вместо отслеживания устройств или событий безопасности, UBA отслеживает пользователей системы.Платформы больших данных, такие как Apache Hadoop, расширяют функциональность UBA, позволяя им анализировать данные объемом в петабайты для обнаружения внутренних угроз и расширенных постоянных угроз.
Проблема этого подхода заключается в том, что он основан на отрицательном обнаружении.модель, которая пытается идентифицировать плохих парней на основе шаблонов и имеет тенденцию иметь ложные срабатывания, что приводит к ослаблению политики блокирования, чтобы не пропустить законных пользователей, а это означает, что некоторые плохие парни всегда найдут свой путь.
ВОЗМОЖНОЕ РЕШЕНИЕ
Например, я хотел бы иметь мобильное приложение и веб-приложение, но я не хочу, чтобы кто-либо еще разрабатывал приложения, которые взаимодействовали бы с этим API.
Для веб-приложения
Для вашего веб-приложения я бы использовал reCAPTCHA V3 на всех страницах веб-сайта, чтобы позволить Google отличать людей от ботов.Это обнаружение выполняется в фоновом режиме, не требуя взаимодействия с пользователем.
Google reCAPTCHA V3 :
reCAPTCHA - это бесплатная служба, защищающая ваш сайт от спама.и злоупотребления.reCAPTCHA использует усовершенствованный механизм анализа рисков и адаптивные задачи, чтобы автоматизированное программное обеспечение не использовалось для злоупотреблений на вашем сайте.Он делает это, позволяя вашим действительным пользователям легко проходить через него.
... помогает вам обнаруживать оскорбительный трафик на вашем сайте без каких-либо проблем со стороны пользователей.Он возвращает оценку, основанную на взаимодействиях с вашим веб-сайтом, и предоставляет вам большую гибкость для принятия соответствующих действий.
Сам по себе этого будет недостаточно, и он также будет иметь ложные срабатывания, как только обнаружение будет отрицательныммодель, но это хорошее начало, чтобы оставить в покое сценаристов.
Для наиболее решительных злоумышленников вам нужно будет использовать уже упомянутые решения WAF и UBA, и эти из них будут более сложными для развертывания и поддержки., но еще раз они работают с максимальной отдачей и не смогут устранить злоупотребления API.
Для мобильных приложений
Limit and Hide Secrets
Первый шагзаключается в том, чтобы ограничить количество секретов на вашем мобильном телефоне только одной, той, которая используется для доступа к вашему API-серверу, и ко всем остальным службам третьей части, к которым вам нужен доступ из вашего мобильного приложения, вы должны делегировать на сервер API, таким образом, не раскрывая в мобильном приложении ключичтобы получить доступ к вашим услугам третьей стороны.
Вы можете увидеть этот репозиторий для рекламыummy Android-приложение, которое я создал для своего следующего поста в блоге (еще не опубликовано), в котором показаны несколько способов скрыть секреты.Оповещение о спойлере, лучший подход в Android - это этот :
#include <jni.h>
#include <string>
#include "api_key.h"
extern "C" JNIEXPORT jstring JNICALL
Java_com_criticalblue_androidhidesecrets_MainActivity_stringFromJNI(
JNIEnv *env,
jobject /* this */) {
// To add the API_KEY to the mobile app when is compiled you need to:
// * copy `api_key.h.example` to `api_key.h`
// * edit the file and replace this text `place-the-api-key-here` with your desired API_KEY
std::string JNI_API_KEY = ANDROID_HIDE_SECRETS_API_KEY_H;
return env->NewStringUTF(JNI_API_KEY.c_str());
}
Имейте в виду, что вышеупомянутая техника хороша только для того, чтобы очень трудно извлечь секрет при статическом анализеДвоичный файл.
Самый простой способ извлечь секреты, используемые мобильным приложением, заключается в том, что злоумышленник может подключить человека в середине атаки к мобильному приложению на устройстве, которым он управляет, с помощью инструмента, подобного:
MiTM Proxy
Интерактивный перехватывающий HTTP-прокси с поддержкой TLS для тестеров на проникновение и разработчиков программного обеспечения.
С помощью этого инструмента злоумышленник добавитпользовательский ssl-сертификат для устройства и мобильного приложения, чтобы он мог перехватывать и считывать весь https-трафик, что позволяет понять, как происходит обмен данными между мобильным приложением и сервером API для организации автоматической атаки.
Обфускация кода
При сборке релизного двоичного кода всегда запутывайте код, например, Android Studio имеет встроенную поддержку для него, или вы можете использовать коммерческие инструменты для достижения еще лучших результатов.
Закрепление сертификата
При закреплении соединения между мобильным приложением и сервером API мы не допускаем атак типа «человек посередине», поскольку мобильное приложение будет отклонять соединения, которые не используют сертификат от сервера API.
Закрепление сертификата
Пиннинг - это процесс связывания хоста с его ожидаемым сертификатом X509 или открытым ключом.Когда сертификат или открытый ключ известен или виден для хоста, сертификат или открытый ключ связывается или «закрепляется» на хосте.Если допустимо более одного сертификата или открытого ключа, программа хранит набор выводов (по словам Джона Ларимера и Кенни Рута из Google I / O talk).В этом случае объявленная идентификационная информация должна соответствовать одному из элементов в наборе символов.
Аттестация мобильного приложения
Использование решения для аттестации мобильного приложения позволит серверу API узнатьЧТО посылает запросы, тем самым позволяя отвечать только на запросы от подлинного мобильного приложения, отклоняя все другие запросы из небезопасных источников.
Роль службы аттестации мобильных приложений заключается в том, чтобы гарантировать во время выполнения, что вашмобильное приложение не было взломано или не запущено на корневом устройстве, запустив SDK в фоновом режиме, который будет взаимодействовать со службой, работающей в облаке, чтобы подтвердить целостность мобильного приложения и работающего устройства.
При успешной аттестации целостности мобильного приложения выдается кратковременный токен JWT, который подписывается с секретом, о котором знают только сервер API и служба аттестации мобильных приложений в облаке.В случае сбоя при аттестации мобильного приложения токен JWT подписывается секретом, которого сервер API не знает.
Теперь приложение должно отправлять при каждом вызове API токен JWT в заголовках запроса.,Это позволит серверу API обслуживать запросы только тогда, когда он может проверить подпись и время истечения срока действия в токене JWT и отклонить их, если он не прошел проверку.
Как только секрет, используемый службой аттестации мобильных приложений, не являетсяизвестное мобильному приложению, невозможно выполнить его реинжиниринг во время выполнения, даже когда приложение подделано, работает на корневом устройстве или осуществляет связь по соединению, которое является целью «человека в средней атаке».
Таким образом, это решение работает в модели положительного обнаружения без ложных срабатываний, таким образом, не блокируя законных пользователей, удерживая плохих парней в отсеках.
Служба аттестации мобильных приложений уже существует как решение SAAS на Approov (я работаю здесь), который предоставляет SDK для нескольких платформ, включая iOS, Android, React Native и другие.Для интеграции также потребуется небольшая проверка кода сервера API для проверки токена JWT, выпущенного облачной службой.Эта проверка необходима для того, чтобы сервер API мог решать, какие запросы обслуживать, а какие отклонять.
ЗАКЛЮЧЕНИЕ
В конце концов все зависит от того, насколько ценным являетсяИмеющиеся у вас данные, каковы последствия для бизнеса нарушения данных, и какие правила вам необходимо соблюдать для этих данных, например, ВВП в Европе.
Таким образом, исходя из этой оценки, вы должны решить, сколько уровней защиты вы хотите применить к своему API, обслуживающему веб-приложения и мобильные приложения.