shipfast api protection
vor, improvments, fixes and security updates
Добро пожаловать! Этот репозиторий является частью этой серии сообщений в блоге о практических методах безопасности API. Серия проходит через процесс защиты мобильного бэкэнда API от различных эксплойтов, которые злоумышленник может использовать для получения доступа к данным, которые он содержит. В этом демонстрационном сценарии атака позволяет реальным пользователям системы получить несправедливое преимущество в бизнесе за счет компании.
Этот репозиторий содержит все три компонента, которые используются для описания истории Shipfast:
Мы сохранили все 3 проекта в одном и том же хранилище и структурировали код, чтобы включить все шаги от прогресса серии блогов. Мы надеемся, что это облегчит понимание в целом.
После установки сцены в первом сообщении в блоге последовательные записи показывают, как меры безопасности могут быть укреплены (или обходятся), используя ссылки на код в этом хранилище GitHub, где это необходимо. Серия блогов может быть обобщена, ссылаясь на основной метод безопасности, обсуждаемый в каждом из них:
Мы предоставляем свободно доступные развертывания двух сервисов и APK для загрузки и установки, чтобы вы могли работать с ними, когда вы читаете блог. В следующих разделах дается краткое изложение услуг, которые мы развернули, приложения, которые мы предоставляем, где можно найти связанный код в этом репозитории и где находятся изменения для каждого поста в блоге.
Код API Shipfast можно найти в папке Server/Shipfast-API. Код развернут в облаке и предоставляется по адресу https://shipfast.demo.approov.io.
API Shipfast версирован от v1 до v4 , чтобы следовать истории блога, и вы можете получить доступ к каждому этапу, используя следующие URL:
Страница выпуска этого репозитория содержит APK для каждого этапа. Они настроены так, чтобы вы могли установить все их одновременно на устройство Android (извините, нет iOS на данный момент).
Код для приложений находится в одном проекте AndroidStudio: App/Android/Kotlin/Shipfast.
Мы использовали различную цветовую схему в каждой версии приложения, чтобы вы могли быстро определить, какой из них работает:
Цвета не имеют особого значения, но, очевидно, зеленый - лучший.
Веб -сервис Rogue, Shipraider, был настроен злым пиратом, чтобы помочь водителям Shipfast воспользоваться преимуществами Shipfast Customers. Код можно найти в папке Server/Shiprider-Rogue-Web.
Каждая версия веб -сайта обслуживается из другого домена:
Веб -сайт Shipraider следует той же цветовой схеме, что и мобильные приложения, чтобы различать версии.
Ниже мы даем краткий обзор методов, используемых в серии блогов для блокировки API со ссылками на соответствующие строки кода и соответствующее сообщение в блоге.
Наиболее распространенный метод, используемый разработчиками для определения того, что делает запрос на сервер API,-это использовать длинную строку в заголовке запроса, чаще всего называемый Api-Key , см. Первый пост в блоге.
Ключи API очень просты для реализации как на сервере, так и на клиенте. Этот код приложения добавляет ключ к каждому запросу, и сервер проверяет запрос с помощью простой проверки заголовка, как показано в этом коде.
К сожалению, обход защиты ключей API также прост, так как это секрет, сообщаемый по каждому запросу. Второй блог в серии начинается с того, что показывает, как извлечь ключ API атакой MITM (человек в середине). Затем ключ добавляется на веб -сайт Shipraider, который будет использоваться в запросах, которые он делает для API Shipfast.
Чтобы улучшить защиту, второй пост в блоге представляет HMAC для цифровой подписи API -запросов и, следовательно, предотвращает их похищенные или подделанные. Он лучше, чем ключ API, так как секретная часть никогда не отправляется от клиента на сервер, и в этой версии она статически встроена в код.
Реализация HMAC немного более сложна, чем реализация ключа API, но она все еще проста. Вы можете проверить этот код для реализации API -сервера и этого кода для реализации мобильного приложения.
Однако, если секрет HMAC жестко кодируется, то злоумышленник все еще легко извлечь. Третий пост в блоге демонстрирует это с использованием инструментов бинарного анализа с открытым исходным кодом, чтобы выявить секрет HMAC и связанный алгоритм, используемый для подписи запросов. После того, как они скопированы в код Shipraider, веб -сайт Rogue может снова начать работу.
Второй сценарий атаки показал, что использование статического секрета для алгоритма HMAC является слабой точкой. Следующая защита - использовать динамический секрет; тот, который вычисляется во время выполнения. Третий пост в блоге объясняет, как объединить статический секрет с динамическими данными, чтобы получить динамический секрет, с помощью которого можно инициализировать алгоритм HMAC.
Реализация для мобильного приложения можно увидеть в этих строках кода, в то время как здесь можно увидеть эквивалент сервера API.
Вычисление HMAC Secret во время выполнения затрудняет обход, но не невозможно. Злоумышленник теперь должен понять более крупный раздел кода, чтобы воспроизвести поведение на веб -сайте Shapraider. В четвертом сообщении в блоге перечислены несколько подходов для этого, приводящих более подробный пример с использованием переупаковки приложений и отладчика Android Studio. Опять же, злоумышленник может написать эквивалентный код в Shipraider, чтобы продолжить использование API Shipfast.
Четвертый пост в блоге представляет окончательную меру безопасности в серии. Аттестация мобильного приложения - это концепция безопасности API, реализованную в Aupv. Короче говоря, Oupov проверяет все приложение и среду, в которой оно работает, прежде чем обеспечить доступ к API - приложение является ключом . Это придает вам высокую степень уверенности в том, что ваши API-образные доступа заблокированы в законных случаях вашего приложения. Этот подход более подробно описывается на нашей странице обзора продукта и в связанной белой статье.
Интеграция AupV настолько проста, насколько это возможно для разработчиков мобильных приложений. Добавьте приведенный SDK в вашу сборку, надеясь, что используя один из примеров [QuickStart Integration]] (https://approov.io/docs/latest/approov-integration-examples/mobile-app/), чтобы ускорить процесс, а затем позвоните в SDK, чтобы получить токен, чтобы включить запросы API. Вы можете увидеть это в приложении Shipfast в ShipfastApp.kt, поиск строк, которым предшествует // *** UNCOMMENT THE CODE BELOW FOR APPROOV *** .
Интеграция API -сервера также проста: используйте одну из многих библиотек JWT, чтобы проверить токен Oupov, прежде чем отвечать на запросы API. API Shipfast использует пакет Node Express-JWT, чтобы проверить токен опередить с помощью обратного вызова checkApproovToken .
Дополнительный документ об использовании описывает шаги построения и развертывания для каждого из компонентов, которые составляют услуги Shipfast и Shiprider. Чтобы следить за серией блогов, обычно достаточно использовать услуги и приложения, развернутые и поддерживаемые командой Oupv, и в этом случае вам не нужно следовать этому документу. Тем не менее, вам понадобится, если вы попробуете дополнительную проблему с пробранным пентерингом, описанную в конце последнего сообщения в блоге.
Серия блогов в целом показывает постепенное улучшение безопасности API, гарантируя, что запросы поступают только из законных источников. Блоги и код в этом репозитории используются, чтобы показать, как легко обойти некоторые механизмы защиты, которые обычно используются в разработке API. Это завершается интеграцией, которая придает наивысшую степень уверенности в проверенных запросах, полученных ShipFast API. Если вы хотите изучить решение о выходе в более подробную информацию, то почему бы не попробовать одну из следующих ссылок в качестве точки прыжка:
