Ваше происхождение проблемы
Недавно я обнаружил, что некоторым людям удалось перепроектировать мое приложение и вызывать API с помощью таких инструментов, как Postman.
Ваша проблема может возникать в Reverse Engineering в сочетании с использованием Instrumentation Framework во время выполнения или с помощью атаки MitM.
Reverse Engineer
Недавно я узналчто некоторые люди смогли перепроектировать мое приложение и вызывают API, используя такие инструменты, как Postman. Я предполагаю, что они обнаружили поток аутентификации, используя инструменты декомпиляции APK.
Так что да, злоумышленник может перепроектировать ваш APK и затем понять ваш рабочий процесс, и для этого он может использовать инструмент с открытым исходным кодом, такой как Mobile Security Framework :
Mobile Security Framework - это автоматизированная универсальная платформа для тестирования пера мобильного приложения (Android / iOS / Windows), позволяющая выполнять статический анализ, динамический анализ, анализ вредоносных программ и тестирование веб-API.
Используя этот или другой инструмент для декомпиляции вашего APK, они могут понять, какой метод возвращает токен JWT, а затем во время выполнения они могут подключить инструментальную рамочную работу, такую как Frida или Xposed для этого метода, чтобыв состоянии извлечь токен JWT, это в устройстве, которым они управляют.
Frida
Внедрение собственных сценариев в процессы черного ящика. Подключите любую функцию, следите за крипто-API или отслеживайте частный код приложения, исходный код не требуется. Отредактируйте, нажмите «Сохранить» и мгновенно увидите результаты. Все без шагов компиляции или перезапусков программы.
xPposed
Xposed - это платформа для модулей, которая может изменять поведение системы и приложений безкасаясь любых APK. Это здорово, потому что это означает, что модули могут работать для разных версий и даже ПЗУ без каких-либо изменений (при условии, что исходный код не был изменен слишком сильно). Отменить это также легко.
Еще один более изощренный подход, который может использовать злоумышленник, - это настройка встроенного портала бесплатного Wi-Fi в публичном пространстве, где он может обманом заставить пользователя установить другой мобильный телефон. приложение со встроенной инструментарий, которая извлекает токен JWT и отправляет его на сервер управления и контроля (C & CS). Позже они могут использовать C & CS для запуска автоматических атак с использованием украденных токенов JWT или просто выполнять ручные атаки на ваши API-интерфейсы как подлинный пользователь.
Сервер командования и управления :
Командно-управляющий [C & C] сервер - это компьютер, управляемый злоумышленником или киберпреступником, который используется для отправки команд системам, подвергаемым опасности со стороны вредоносных программ, и получения украденных данных из целевой сети. Многие кампании были обнаружены с использованием облачных сервисов, таких как веб-почта и файлообменники, в качестве серверов C & C, чтобы смешаться с обычным трафиком и избежать обнаружения.
MitM Attack
и вызывают API-интерфейсы с помощью таких инструментов, как Postman.
Самый простой способ получить токен JWT - атакующий выполняет атаку MitM на устройстве, которым он управляет, и затем он может простозапускать автоматические или ручные атаки.
Прокси-инструментом с открытым исходным кодом для MitM-атак является mitmproxy :
Интерактивный TLS-перехватывающий прокси-сервер HTTP для тестировщиков проникновенияи разработчики программного обеспечения.
Вы можете увидеть, как использовать его для извлечения секрета из запроса в статье, которую я написал Украсть этот ключ API с помощью MitM Attack :
Итак, в этой статье вы узнаете, как настроить и запустить MitM-атаку для перехвата https-трафика на мобильном устройстве под вашим контролем, чтобы вы могли украсть ключ API. Наконец, на высоком уровне вы увидите, как можно смягчить атаки MitM.
Также возможно запуск атаки MitM с использованием захваченного портала, и здесь злоумышленник обманом заставит пользователя загрузить свои собственные сертификаты на пользовательское устройство, но, начиная с уровня API Android 24, ваше мобильное приложение доверяет толькосистемные сертификаты, если вы явно не укажете в файле конфигурации сетевой безопасности, что он может доверять предоставленным пользователем сертификатам. Поэтому, если у вас нет пользователей на старых устройствах, и ваше приложение не дает явного согласия на доверие к предоставленным пользователем сертификатам, вы защищены от этой атаки.
Возможные решения
Мне интересно, какой подход я могу использовать для решения этой проблемы, либо выявляя нарушителей, чтобы я мог их запретить, либо вообще предотвращая их.
Вы можете использовать базовую защиту API или некоторые более продвинутые, но я думаю, что вам нужно решение для аттестации мобильных приложений, но давайте сначала рассмотрим каждое из ваших возможных решений, но преждеМы углубимся в возможные решения, давайте сначала исправим распространенный недостаток знаний среди разработчиков.
Кто против того, что обращается к API-серверу
Обычная проблема среди разработчиков заключается в том, что они неосознает разницу между WHO против WHAT , обращающимся к API-серверу, и очень важно понять, как можно защитить от атак API против атак мобильных приложений.
Для лучшего понимания разницы между WHO против WHAT обращается к вашему API-серверу, я рекомендую вам прочитать этот раздел моей статьи, но я извлекуВот несколько строк этого:
, который является пользователем мобильного приложения, которое мы можем аутентифицировать, авторизовать и идентифицировать в нескольких случаях. Можно использовать OpenID Connect или потоки OAUTH2.
what - это то, что делает запрос к серверу API. Действительно ли это подлинный экземпляр вашего мобильного приложения, или это бот, автоматизированный скрипт или злоумышленник, который вручную ковыряется в вашем API-сервере с помощью такого инструмента, как Postman?
Базовые защиты API-интерфейса
Теперь, когда вы понимаете разницу между , кто против , что обращается к вашему API-серверу, вы можете прочитать мою статью об основных приемахдля защиты API:
В этой статье мы рассмотрим наиболее распространенные методы, используемые для защиты API, включая то, насколько важно использовать HTTPS для защиты канала связи между мобильным приложением и API, какКлючи API используются для идентификации мобильного приложения при каждом запросе API, как пользовательские агенты, капчи и IP-адреса используются для предотвращения ботов, и, наконец, насколько важна аутентификация пользователей для безопасности мобильных устройств и API-интерфейсов. Мы обсудим каждый из этих методов и обсудим, как они влияют на профиль бизнес-рисков, т. Е. Насколько легко они обходятся.
Дополнительные расширенные средства защиты API
Вы можете начать с чтенияЭта серия статей о Mobile API Security Techniques , чтобы понять, как ключи API, HMAC, OAUTH и закрепление сертификатов могут использоваться для повышения безопасности и в то же время, как ими можно злоупотреблять /побежден.
Впоследствии, в зависимости от вашего бюджета и ресурсов, вы можете использовать множество различных подходов и методов для защиты вашего API-сервера, и я начну перечислять некоторые из самых обычных.
Вы можете начать с reCaptcha V3 , за которым следует Брандмауэр веб-приложений (WAF) и, наконец, если вы можете позволить себе это решение User Behavior Analytics (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 будет отправлен любой запрос.
Аттестация мобильного приложения
Наконецесли у вас есть ресурсы, вы можете пойти еще дальше, создав собственное решение Mobile APP Attestation :
Роль службы аттестации мобильных приложений заключается в проверке подлинности того, что отправляетзапросы, таким образом, только отвечая на запросы, исходящие от подлинных экземпляров мобильного приложения, и отклоняя все остальные запросы от неавторизованных источников.
Чтобы узнать, что отправляет запросы на сервер API, службу аттестации мобильных приложений. во время выполнения идентифицирует с высокой степенью уверенности в том, что ваше мобильное приложение присутствует, не было взломано / переупаковано, не запущено в корневом устройстве, не было подключено инструментарием (Frida, xPposed, Cydia и т. д.). .) и не является объектом «Человек в средней атаке» (MitM). Это достигается путем запуска SDK в фоновом режиме, который будет взаимодействовать со службой, работающей в облаке, чтобы подтвердить целостность мобильного приложения и устройства, на котором оно работает.
При успешном подтверждении целостности мобильного приложения выдается кратковременный токен JWT, который подписывается с секретом, который известен только облачному API-серверу и службе подтверждения мобильных приложений в облаке. В случае неудачной аттестации токен JWT подписывается с неверным секретом. Поскольку секрет, используемый службой аттестации мобильных приложений, не известен мобильному приложению, невозможно выполнить обратный инжиниринг его во время выполнения, даже если приложение было взломано, запущено на корневом устройстве или обменивается данными через соединениеэто цель атаки MitM.
Мобильное приложение должно отправлять токен JWT в заголовке каждого запроса API. Это позволяет серверу API обслуживать запросы только в том случае, если он может проверить, что токен JWT был подписан общим секретом и срок его действия не истек. Все остальные запросы будут отклонены. Другими словами, действительный токен JWT сообщает серверу API, что запрос выполняет подлинное мобильное приложение, загруженное в магазин Google или Apple, в то время как неверный или отсутствующий токен JWT означает, что то, что делает запрос, не авторизовано для этого. поскольку это может быть бот, переупакованное приложение или злоумышленник, выполняющий атаку MitM.
Большим преимуществом использования службы аттестации мобильных приложений является ее проактивная и позитивная модель аутентификации, которая не создает ложных срабатываний,и, таким образом, не блокирует законных пользователей, в то время как он удерживает плохих парней в страхе.
Резюме
На мой взгляд, лучшее решение - это глубокая защита, применяя столько слоев, сколько выможет, чтобы вы увеличили время, усилия и набор навыков, необходимых для обхода всех ваших уровней безопасности, таким образом не давая детям и большинству хакеров возможности злоупотреблять вашим сервисом.
Поэтому вам следует нанятьимеет много методов, насколько это возможно в обеих сторонах уравнения, мобильное приложениеи API, как те, которые вы узнали при чтении статей, которые я связал: HTTPS, ключи API, пользовательские агенты, капчи, ограничение скорости, OAuth, HMAC, закрепление сертификатов, обфускация кода, JNI / NDK для скрытия секретов, WAF, UBAи т. д.
В конце концов, решение, которое будет использоваться для защиты вашего API-сервера, должно быть выбрано в соответствии со значением того, что вы пытаетесь защитить, и с юридическими требованиями для этого типа данных, такими какнормативы GDPR в Европе.
Пройдя лишнюю милю
Я настоятельно рекомендую вам также взглянуть на OWASP Mobile Security Project - Топ-10 рисков
OWASP Mobile Security Project - это централизованный ресурс, предназначенный для того, чтобы предоставить разработчикам и командам безопасности ресурсы, необходимые для создания и поддержки защищенных мобильных приложений. В рамках проекта наша цель состоит в том, чтобы классифицировать риски для мобильной безопасности и обеспечить средства контроля развития, чтобы уменьшить их влияние или вероятность эксплуатации.