БЛОКИРОВКА СЕРВЕРА API ДЛЯ МОБИЛЬНОГО ПРИЛОЖЕНИЯ
У меня есть мобильная игра, которая взаимодействует с API. Я хочу, чтобы этот API вызывался только из этого мобильного приложения. Это просто объяснить, но, с другой стороны, его простота делает меня хаотичным c.
В разработке программного обеспечения часто бывает так, что вещи, которые легко объяснить, могут быть очень сложными для реализации, и это один из таких случаев.
Итак, чего вы хотите добиться, так это заблокировать ваш сервер API для вашего мобильного приложения, или другими словами, чтобы ваш сервер APi отвечал только на запросы, поступающие от вашего подлинного и незащищенного мобильное приложение, которое вы загрузили в официальные магазины.
Вы упомянули, что пользователей нет:
Пользователей нет, поэтому учетных данных нет. Это открытая игра, которая запрашивает изображение у API.
Но я думаю, вы, возможно, захотите сказать, что у вас нет аутентифицированных пользователей , и даже у вас они есть у вас будет идентифицировать только Кто в запросе, а не Что выполняет запрос.
Это распространенное заблуждение среди разработчиков, независимо от того, младший или старший, таким образом важно правильно его очистить, чтобы вы могли разработать эффективное безопасное решение для своего мобильного приложения.
Разница между ВОЗ и ЧТО обеспечивает доступ к API-серверу
Я написал серию статей об API и мобильной безопасности, и одна из них содержит хорошее описание этой разницы, статья Зачем вашему мобильному приложению нужен ключ API? - это та, которую вы хотите прочитать, чтобы лучше понять разницу между Кто и Что получает доступ к вашему API-серверу, но я извлеку здесь основные выводы:
что * 1 039 * - это то, что делает запрос к серверу API. Действительно ли это подлинный экземпляр вашего мобильного приложения, или это бот, автоматизированный скрипт или злоумышленник, вручную копающийся в вашем API-сервере с помощью такого инструмента, как Postman?
who пользователь мобильного приложения, которое мы можем аутентифицировать, авторизовать и идентифицировать несколькими способами, например, используя OpenID Connect или потоки OAUTH2.
Подумайте о Who как о пользовательском API Сервер сможет аутентифицировать и авторизовать доступ к данным и думать о What как о программном обеспечении, которое выполняет этот запрос от имени пользователя.
Так что в вашей ситуации вы не беспокоитесь о Who в запросе, вместо этого вы хотите знать Что выполняет запрос, чтобы вы могли привязать свой сервер API к вашему подлинному мобильному приложению.
Hardcoded Идентификаторы
Секретный код / apikey / token et c. -> Ничто не должно быть жестко закодировано
Это очень мудрое решение, потому что с момента выпуска мобильного приложения любая конфиденциальная дата внутри него должна рассматриваться как скомпрометированная, поскольку существует множество инструментов с открытым исходным кодом для помочь любому выполнить анализ stati c и динамического c в двоичном файле мобильного приложения, чтобы извлечь эти данные и / или изменить поведение приложения. Примеры инструментов этого типа:
MobSF - Mobile Security Framework
Mobile Security Framework - это автоматизированное мобильное приложение «все в одном» (Android) / iOS / Windows) фреймворк для ручного тестирования, способный выполнять анализ stati c, динамический анализ c, анализ вредоносных программ и тестирование веб-API.
Frida
Внедрение собственных сценариев в процессы черного ящика. Подключите любую функцию, следите за крипто API или отслеживайте частный код приложения, исходный код не требуется. Отредактируйте, нажмите Сохранить и мгновенно увидите результаты. Все без шагов компиляции или перезапуска программы.
Идентификаторы времени выполнения
Идентификатор устройства или Рекламный идентификатор -> Хорошее решение, но любые другие приложения также получают этот идентификатор, а затем вызывают мой API. Плюс, любой злоумышленник может отправить что-нибудь как Device ID, верно? Итак, как я могу убедиться, что этот идентификатор устройства является реальным идентификатором для существующего устройства?
Эти идентификаторы легко манипулируются / извлекаются во время выполнения с помощью таких сред, как Frida или Cydia, поэтому они открыты для эксплуатации. злоумышленником, как вы уже догадались.
Теперь, если вы ссылаетесь на более сложные идентификаторы, такие как Android Safet yNet и / или iOS DeviceCheck , тогда я хочу Обращаю ваше внимание на некоторые детали:
Android Safet yNET
Вы можете прочитать мой ответ на вопрос Android эквивалент ios devicecheck , который очень подробно рассказывает о том, что это такое, а что нет.
Но вкратце он не был предназначен для использования в качестве отдельной защиты в соответствии с собственным заявлением Google :
Цель этого API - предоставить вам уверенность в целостности устройства, на котором работает ваше приложение. Затем вы можете получить дополнительные сигналы, используя стандартные API Android. Вы должны использовать API аттестации Safet yNet в качестве дополнительного сигнала глубокой защиты как часть системы защиты от злоупотреблений, а не как единственный сигнал защиты от злоупотреблений для вашего приложения.
iOS DeviceCheck
Решение Apple DeviceCheck от Apple в первую очередь предназначено для проверки личности и отслеживания физического мобильного устройства без необходимости отслеживать какую-либо личную информацию об устройстве или его пользователь:
Используя API-интерфейсы DeviceCheck в сочетании с API-интерфейсами сервер-сервер, вы можете устанавливать и запрашивать два бита данных на устройство, сохраняя при этом конфиденциальность пользователя. Вы можете использовать эти данные для идентификации устройств, которые уже воспользовались рекламным предложением, которое вы предоставляете, ...
И, как говорят, вы также можете использовать его для маркировки устройства как cfraudlent:
... или пометить устройство, которое вы определили как мошенническое. API-интерфейсы DeviceCheck также позволяют вам проверить, что полученный вами токен получен с устройства c Apple, на которое было загружено ваше приложение.
Но не забывайте слова, которые они используют: для пометить устройство, которое вы определили как мошенническое . Таким образом, вы должны определить состояние устройства, но помните, что знать, что устройство рутовано или сломано, это не то же самое, что знать Что делает запрос к серверу API.
Так я должен их использовать? Да, потому что защита - это добавление столько слоев, сколько вы можете себе позволить, но это не решит вашу главную проблему, а именно: Что делает запрос к вашему API-серверу.
Сервер аутентификации
Я рассматриваю возможность использования AWS Cognito в качестве сервера аутентификации.
Независимо от того, превосходят ли Cognito или любой другой сервер аутентификации в идентификации, аутентификации и авторизовать Кто находится в запросе, но они не знают, как сделать то же самое для Что выполняет запрос.
ВОЗМОЖНОЕ РЕШЕНИЕ
Я хочу, чтобы этот API вызывался только из этого мобильного приложения. Итак, как я могу убедиться, что этот идентификатор устройства является реальным идентификатором для существующего устройства?
Чтобы узнать, что То, что делает запрос, действительно является вашим подлинным и неизмененным экземпляром ваше мобильное приложение, вам нужно использовать концепцию аттестации мобильных приложений, которую я описываю в этом ответе на вопрос Как обезопасить API REST для мобильного приложения? , особенно разделы для Защита сервера API и Возможное лучшее решение .
ВЫ ХОТИТЕ GO ДОПОЛНИТЕЛЬНУЮ МИЛЬ?
Не могу закончить sh мой ответ без ссылки на отличную работу от фонда OW ASP.
для мобильных приложений
OW ASP Проект Mobile Security - 10 основных рисков
OW ASP Mobile Security Project - это централизованный ресурс, предназначенный для предоставления разработчикам и командам безопасности ресурсов, необходимых для создания и поддержки защищенных мобильных приложений. В рамках проекта наша цель состоит в том, чтобы классифицировать риски для безопасности мобильных устройств и обеспечить средства управления развитием, чтобы уменьшить их влияние или вероятность эксплуатации.
OW ASP - Руководство по тестированию мобильной безопасности :
Руководство по тестированию безопасности мобильных устройств (MSTG) - это всеобъемлющее руководство по разработке, тестированию и реверс-инжинирингу безопасности мобильных приложений.
Для APIS
OW ASP API Security Top 10
OW ASP API Security Project стремится обеспечить ценность разработчикам программного обеспечения и оценщикам безопасности, подчеркивая потенциальные риски в небезопасных API, и иллюстрирующий, как эти риски могут быть смягчены. Для достижения этой цели проект безопасности API OW ASP создаст и будет поддерживать документ «Топ 10 угроз безопасности API», а также портал документации для рекомендаций по созданию и оценке API.