Как определить приложение или веб-сайт, который вызывает конечную точку API? - PullRequest
0 голосов
/ 18 апреля 2020

Мы делаем API в PHP. Мы хотим, чтобы конечные точки API вызывались только некоторыми указанными приложениями и веб-сайтами (не через Почтальон или любое подобное программное обеспечение). Мы попытались отправить некоторые ключ аутентификации с вызовом, но есть инструменты , которые можно использовать для получения всего кода даже из signed APK (протестировано на apk WhatsApp) , так что ключ мог просочиться.

Итак, мы пытаемся выяснить, есть ли способ идентифицировать приложение вызывающего абонента или веб-сайт для нашего API endpoint, тогда мы проверим личность в PHP и передадим response соответственно.

Есть ли способ достичь этого? Если нет, то есть ли какая-то другая работа?

Заранее спасибо.

1 Ответ

1 голос
/ 21 апреля 2020

ВЫЗОВ

Мы хотим, чтобы конечные точки API вызывались только некоторыми указанными приложениями и веб-сайтами (не через Postman или аналогичное программное обеспечение).

Ну, вы столкнулись с огромной проблемой, и очень трудной для ее решения.

Прежде чем углубляться в детали, я могу сказать, что проще защитить API, который служит только мобильные приложения, а затем API, который обслуживает как мобильные приложения, так и веб-приложения.

В качестве предупреждения о спойлере я могу сказать, что для веб-приложения сервер API лучше всего использовать искусственный интеллект для защиты от подлинных запросов, в то время как для мобильного приложения решение является более эффективным и простым, когда сервер API может подтвердить, что мобильное приложение, выполняющее запрос, является подлинным и неизмененным.

ОБРАТНАЯ ИНЖИНИРИНГ

Природа из того, как был создан веб, очень легко анализировать код на стороне клиента, иначе вам просто нужно нажать F12 или щелкнуть правой кнопкой мыши, чтобы просмотреть исходный код страницы, таким образом, легко выполнить обратную разработку любого самозащитного кода или извлекать любые секреты, используемые для идентификации приложения, на сервер API.

Для мобильных приложений это не так просто, но я Это не так сложно, потому что у нас есть отличные инструменты с открытым исходным кодом, которые помогут нам с этим, такие как Mobile Security Framework (MoBSF) , который объединяет несколько инструментов в одном веб-интерфейсе, что сделает его легким для изменения разработайте и извлеките исходный код и секреты подписанного APK, как вы достигли с помощью приложения What:

We have tried to send some authentication key with the call but there are tools which can be used to get the entire code even from a signed APK(tested on the apk of whatsApp), so the key could get leaked. 

Секреты в мобильном приложении можно сложно извлечь с помощью бинарного анализа stati c как я покажу в этой статье :

В этой статье мы будем использовать исследовательский репозиторий Android Hide Secrets , который является фиктивным мобильным приложением с API ключи скрыты с использованием нескольких различных методов.

В этой статье показано, как использовать собственный интерфейс JNI / NDK , чтобы скрыть секреты в коде C, что делает его очень сложным для извлечения, но тогда вы не можете сделать это с помощью stati c анализа, вы делаете это динамически с помощью MiTM Proxy атаки, как я описал в этой другой a статья:

Man in the Middle Attack

Чтобы продемонстрировать, как украсть ключ API, я создал и выпустил в Github демонстрационную версию конвертера валют приложение для Android, которое использует ту же технику JNI / NDK, которую мы использовали в предыдущем Android приложении Hide Secrets, чтобы скрыть ключ API. SERVER

Итак, мы пытаемся выяснить, существует ли способ идентифицировать приложение вызывающего абонента или веб-сайт для нашей конечной точки API, тогда мы проверим идентичность в PHP и дадим соответствующий ответ.

Таким образом, благодаря всем этим инструментам и легкому доступу для обратного инжиниринга приложения API-серверу становится очень сложно отличить Кто находится в запросе от Что выполняет запрос и понимает разницу между Кто и Что Важно, чтобы разработчик мог определить стратегию безопасности для своих серверов API и приложений. Поскольку это понятие, которое чаще всего неправильно понимается разработчиками, я рекомендую вам прочитать этот раздел статьи, которую я написал, которая объясняет это более подробно, и откуда я цитирую:

what - это то, что делает запрос к серверу API. Это действительно подлинный экземпляр вашего мобильного приложения, или это бот, автоматизированный скрипт или злоумышленник, который вручную ковыряется в вашем API-сервере с помощью такого инструмента, как Postman?

who пользователь мобильного приложения, которое мы можем аутентифицировать, авторизовать и идентифицировать несколькими способами, например, используя OpenID Connect или потоки OAUTH2.

Итак, подумайте о Who как о пользователе, которого ваш API-сервер сможет аутентифицировать и авторизовать доступ к данным, и подумайте о What как о программном обеспечении, которое выполняет этот запрос в от имени пользователя, например, Postman или cURL.

После устранения этой разницы вы теперь в лучшем положении, чтобы принимать решения о том, как вы будете решать вопросы безопасности своего сервера API и приложений.

ИДЕНТИФИКАЦИЯ КТО И ЧТО В ЗАПРОСЕ

Есть ли способ достичь этого? Если нет, то есть ли какая-нибудь другая работа?

Чтобы определить Кто в запросе, вы можете прибегнуть к традиционным механизмам аутентификации и авторизации или использовать OAuth2 или OpenID Connect .

Чтобы определить Что в запросе - это то место, где он находится, потому что ваш сервер API должен различать Кто из Что , и некоторые продвинутые подходы будут использовать Аналитика поведения пользователя (UBA) для достижения этой цели.

Примером решения UBA является [ Google reCAPTCHA V3 ], который не требует взаимодействия с пользователем и дает оценку API-серверу в том, насколько вероятен запрос от Человека или нет.

Хотя это работает лучше всего Несмотря на усилия, направленные на то, чтобы отличать людей от машин, она не может дать очень высокую степень уверенности в том, что вы не столкнетесь с ложными срабатываниями, но решения UBA - ваш лучший шанс для обслуживания сервера API. веб-приложения

Для сервера API, обслуживающего мобильные приложения, мы можем использовать концепцию аттестации мобильных приложений, чтобы иметь эффективный способ узнать Что выполняет запрос, и я рекомендую вам go и прочитайте этот ответ Я дал на вопрос Как обезопасить API REST для мобильного приложения? , который посоветует вам окончательное решение, похожее на это:

Access the API Server via Proxy without embedded secrets in the Mobile App

Прочитайте ответ, который я связал, чтобы понять, как аттестация мобильных приложений позволит удалять секреты из мобильного приложения и дать вашему API-серверу высокую степень уверенности в знании Что делает запрос.

ВЫ ХОТИТЕ GO ДОПОЛНИТЕЛЬНУЮ МИЛЬУ?

В любом ответе на секретный вопрос я хотел бы сослаться на отличную работу из фонда OW ASP.

Для веб-приложений

OW ASP Топ 10 веб-рисков

OW ASP Top 10 - мощный информационный документ для безопасности веб-приложений , Он представляет широкий консенсус в отношении наиболее критических угроз безопасности для веб-приложений. В число участников проекта входят различные эксперты по безопасности со всего мира, которые поделились своим опытом для составления этого списка.

Руководство по тестированию веб-безопасности :

OW ASP Руководство по тестированию веб-безопасности включает в себя инфраструктуру тестирования на проникновение «передовой опыт», которую пользователи могут внедрять в своих организациях, и руководство по тестированию на проникновение «низкого уровня», в котором описываются методы тестирования наиболее распространенных веб-приложений и безопасности веб-сервисов. проблемы.

Для мобильных приложений

OW ASP Проект Mobile Security - 10 основных рисков

OW ASP Mobile Security Project - это централизованный ресурс, предназначенный для предоставления разработчикам и командам безопасности ресурсов, необходимых для создания и поддержки защищенных мобильных приложений. В рамках проекта наша цель состоит в том, чтобы классифицировать риски для безопасности мобильных устройств и обеспечить средства управления развитием, чтобы уменьшить их влияние или вероятность эксплуатации.

OW ASP - Руководство по тестированию мобильной безопасности :

Руководство по тестированию безопасности мобильных устройств (MSTG) - это всеобъемлющее руководство по разработке, тестированию и реверс-инжинирингу безопасности мобильных приложений.

Для APIS

OW ASP API Top 10

Проект безопасности API OW ASP стремится обеспечить ценность разработчикам программного обеспечения и оценщикам безопасности, подчеркивая потенциальные риски в небезопасных API и иллюстрируя, как эти риски могут быть смягчены. Для достижения этой цели проект безопасности API OW ASP создаст и будет поддерживать документ «Топ 10 угроз безопасности API», а также портал документации для рекомендаций по созданию и оценке API.

ССЫЛКИ ССЫЛКИ

Google reCAPTCHA V3 :

reCAPTCHA - это бесплатный сервис, который защищает ваш сайт от спама и злоупотреблений. reCAPTCHA использует усовершенствованный механизм анализа рисков и адаптивные задачи, чтобы автоматизированное программное обеспечение не использовалось для злоупотреблений на вашем сайте. Это делает это, позволяя вашим действительным пользователям легко проходить через них.

... помогает вам обнаружить злоупотребления траффиком c на вашем сайте без каких-либо проблем со стороны пользователя. Он возвращает оценку, основанную на взаимодействиях с вашим веб-сайтом, и предоставляет вам большую гибкость для принятия соответствующих действий.

UBA - Аналитика поведения пользователя :

Аналитика поведения пользователей (UBA) в соответствии с определением Gartner - это процесс кибербезопасности, связанный с обнаружением внутренних угроз, целевых атак и финансового мошенничества. Решения UBA рассматривают модели поведения людей, а затем применяют алгоритмы и статистический анализ для выявления значимых аномалий из этих моделей - аномалий, которые указывают на потенциальные угрозы. Вместо отслеживания устройств или событий безопасности, UBA отслеживает пользователей системы. Платформы больших данных, такие как Apache Had oop, расширяют функциональные возможности UBA, позволяя им анализировать данные объемом в петабайты для обнаружения внутренних угроз и расширенных постоянных угроз.

Mobile Security Framework

Mobile Security Framework - это автоматизированное универсальное мобильное приложение (Android / iOS / Windows) для тестирования пера, способное выполнять анализ stati c, динамический c анализ, анализ вредоносных программ и тестирование веб-API.

OAuth2

OAuth 2.0 - это стандартный отраслевой протокол для авторизации. OAuth 2.0 заменяет работу, проделанную над оригинальным протоколом OAuth, созданным в 2006 году. OAuth 2.0 фокусируется на простоте разработки для клиентов, обеспечивая при этом определенные c потоки авторизации для веб-приложений, настольных приложений, мобильных телефонов и устройств в гостиной. Эта спецификация и ее расширения разрабатываются в рабочей группе IETF OAuth .

OpenID Connect

OpenID Connect 1.0 простой идентификационный уровень поверх протокола OAuth 2.0. Это позволяет клиентам проверять идентичность конечного пользователя на основе аутентификации, выполняемой сервером авторизации, а также получать базовую информацию профиля конечного пользователя c совместимым и REST-подобным образом. OpenID Connect выполняет многие из тех же задач, что и OpenID 2.0, но делает это таким образом, чтобы API-интерфейс был удобен и мог использоваться в собственных и мобильных приложениях. OpenID Connect определяет дополнительные механизмы для надежной подписи и шифрования. В то время как интеграция OAuth 1.0a и OpenID 2.0 требовала расширения, в OpenID Connect возможности OAuth 2.0 интегрированы с самим протоколом.

JNI / NDK :

Используя Android Studio 2.2 и выше, вы можете использовать NDK для компиляции кода C и C ++ в собственную библиотеку и упаковки его в ваш APK с помощью Gradle, интегрированной системы сборки IDE. Ваш код Java может затем вызывать функции в вашей собственной библиотеке через инфраструктуру Java Native Interface (JNI).

...