Я создаю приложение, использующее OpenAI API.
Они предоставляют мне токен API, который я использую для выполнения вызовов API из моего мобильного приложения для Android (реагировать на родной)
Я знаю, что хранить этот токен API в мобильном клиенте — плохая практика, потому что злоумышленники могут использовать его и использовать мою квоту и деньги.
Каковы мои варианты? Тривиальное решение — построить бэкэнд, но я не хочу начинать реализовывать все оригинальные методы API, я просто предпочитаю использовать его прямо из клиента.
Я пытался сохранить токен таким образом, чтобы его нельзя было найти, но не смог найти способ.
@wambada, если мы считаем токены секретами, вы, вероятно, захотите хранить их в диспетчере секретов, а не просто в БД - так что в основном другой уровень: App -> Firestore -> Secret Manager
@wambada У меня нет пользователей в моем приложении
@SharonLifshits Да, это лучшее решение. Вы на месте.
@YardenST Ну, вы должны добавить аутентификацию в свое приложение, чтобы получить ограниченный доступ к вашему токену API.
Они предоставляют мне токен API, который я использую для выполнения вызовов API из моего мобильного приложения для Android (реагировать на родной)
Я знаю, что хранить этот токен API в мобильном клиенте — плохая практика, потому что злоумышленники могут использовать его и использовать мою квоту и деньги.
Да, это действительно очень плохая практика, но, по крайней мере, вы знаете о рисках, в то время как многие используют этот подход, не осознавая, насколько легко злоумышленнику получить такие секреты (токены API, ключи API, как бы вы их ни называли).
В серии статей, посвященных безопасности мобильных API, я показываю, как легко это можно сделать с помощью статического анализа и атаки MitM:
Как извлечь ключ API из мобильного приложения с помощью статического бинарного анализа:
Диапазон инструментов с открытым исходным кодом, доступных для обратного проектирования, огромен, и мы действительно не можем коснуться этой темы в этой статье, но вместо этого мы сосредоточимся на использовании Mobile Security Framework (MobSF), чтобы продемонстрировать, как перепроектировать APK нашего мобильного приложения. MobSF — это набор инструментов с открытым исходным кодом, которые представляют свои результаты в привлекательной панели инструментов, но те же самые инструменты, которые используются внутри MobSF и в других местах, могут использоваться по отдельности для достижения тех же результатов.
В этой статье мы будем использовать исследовательский репозиторий Android Hide Secrets, который представляет собой фиктивное мобильное приложение с ключами API, скрытыми с помощью нескольких различных методов.
Некоторые злоумышленники предпочитают сразу перейти к атаке MitM, потому что они узнают, как приложение взаимодействует с серверной частью API, и извлекут используемые секреты, а также план, который им необходимо использовать для выполнения запроса и анализа ответов.
Украдите этот ключ API с помощью атаки человека посередине:
Чтобы продемонстрировать, как украсть ключ API, я создал и выпустил на Github приложение Currency Converter Demo для Android, в котором используется тот же метод JNI/NDK , который мы использовали в более ранней версии Android. Приложение Hide Secrets , чтобы скрыть ключ API.
Итак, в этой статье вы узнаете, как настроить и запустить MitM-атаку для перехвата https-трафика на мобильном устройстве под вашим контролем, чтобы можно было украсть ключ API. Наконец, вы увидите на высоком уровне, как можно смягчить атаки MitM.
Тривиальное решение — построить бэкэнд, но я не хочу начинать реализовывать все оригинальные методы API, я просто предпочитаю использовать его прямо из клиента.
Вам не нужно, вам просто нужно, чтобы ваш бэкэнд проксировал запросы к стороннему API, который вы используете в своем мобильном приложении, что в вашем случае кажется только для OpenAPI.
Например, когда вашему мобильному приложению нужно сделать запрос к openapi.io/some/resource
, вместо этого оно направляет его к your-reverse-proxy.com/some/resource
, который затем захватит часть /some/resource
и создаст запрос к OpenAPI openapi.io/some/resource
, добавив к нему заголовок токена API, который теперь надежно хранится в вашем Обратный прокси-сервер.
Использование обратного прокси для защиты сторонних API
В этой статье вы начнете с изучения того, что такое сторонние API и почему вам не следует обращаться к ним напрямую из вашего мобильного приложения. Далее вы узнаете, что такое обратный прокси-сервер, а затем узнаете, когда и почему вы должны использовать его для защиты доступа к сторонним API, используемым в вашем мобильном приложении.
Повторяющейся темой в этой статье был совет не обращаться к сторонним API напрямую из мобильного приложения. Как мы уже говорили, как только ваше мобильное приложение выпущено, любой секрет в нем становится общедоступным, поэтому злоумышленники могут использовать его от вашего имени. Если вы не будете осторожны, вы будете тем, кто оплатит счет или обнаружит, что ваши ресурсы бесплатного уровня были исчерпаны кем-то другим.
Недостаток этого подхода заключается в том, что у вас все еще есть ключ API, который вам нужно защитить, тот, который используется для доступа к обратному прокси-серверу, но, по крайней мере, вы не раскрываете свой секрет OpenApi, и вы можете использовать несколько механизмов для ограничения запросов и защиты. доступ к вашему обратному прокси-серверу, чтобы гарантировать, что вы отвечаете только на запросы из подлинных и немодифицированных экземпляров вашего мобильного приложения.
Вы можете разработать или использовать готовый механизм для доставки секретов в ваше мобильное приложение как раз в тот момент, когда они требуются для использования в запросе API, сделанном в OpenAPI, но вам необходимо убедиться, что секреты доставляются только к подлинным и немодифицированным экземплярам вашего мобильного приложения, которые не подвергаются атаке MitM, были подделаны/инструментированы во время выполнения такими инструментами, как Frida, в противном случае ваш секрет будет легко извлечен путем подключения к функции, которая добавляет их в заголовок в API-запрос или путем перехвата запроса с помощью атаки MitM, даже если канал связи защищен с помощью закрепления сертификата, потому что это не так сложно обойти на устройстве, которое контролирует злоумышленник.
В моем ответе на вопрос Безопасное хранение ключей API во Flutter или отправка платежных реквизитов на мой сервер? Более подробно я расскажу о подходе Runtime Secret Protection.
В любом ответе на секретный вопрос я всегда хотел бы сослаться на прекрасную работу фонда OWASP.
Проект OWASP API Security Project направлен на обеспечение ценности для разработчиков программного обеспечения и экспертов по безопасности, подчеркивая потенциальные риски, связанные с небезопасными API, и показывая, как эти риски можно снизить. Для достижения этой цели проект OWASP API Security Project создаст и будет поддерживать документ «10 основных рисков безопасности API», а также портал документации для лучших практик создания или оценки API.
Проект OWASP Mobile Security - 10 главных рисков
Проект OWASP Mobile Security — это централизованный ресурс, предназначенный для предоставления разработчикам и специалистам по безопасности ресурсов, необходимых им для создания и обслуживания безопасных мобильных приложений. В рамках проекта наша цель состоит в том, чтобы классифицировать риски безопасности мобильных устройств и обеспечить контроль разработки, чтобы уменьшить их влияние или вероятность использования.
OWASP - Руководство по тестированию безопасности мобильных устройств:
Руководство по тестированию безопасности мобильных устройств (MSTG) — это подробное руководство по разработке, тестированию и обратному проектированию безопасности мобильных приложений.
Одним из простых решений является использование базы данных FirebaseAuth и CloudFirestore. Вы храните токен API в защищенной базе данных CloudFirestore и ограничиваете доступ для аутентифицированного пользователя. Когда вы входите в систему, вы получаете токен и используете его по своему усмотрению.