Ваш вопрос
Я настроил шаги на бэкэнде, чтобы получить пароль, проверить его и ответить токеном.Единственная проблема - пароль, который я использую на внешнем интерфейсе (мобильное приложение) для проверки на стороне сервера, жестко закодирован.
Мой вопрос:
Как мне безопасно хранить этот парольв мобильном приложении, чтобы хакер не смог его обнаружить и использовать для компрометации бэкэнда?
Жестокая правда в том, что ... вы не можете !!!
Похоже, вы уже провели обширные исследования по этому вопросу, и, по моему мнению, вы упомянули один эффективный способ доставки вашего приложения со встроенным секретом:
Скрытый в собственных библиотеках
Но, как вы также говорите:
Эти методы в основном бесполезны, поскольку хакеры могут легко обойти эти методы защиты.
Некоторые из них бесполезны, а другие делаютреконструировать секрет мобильного приложения намного сложнее.Как я писал здесь , подход к использованию нативных интерфейсов для сокрытия секрета потребует опыта для его реинжиниринга, но тогда, если реэкспроектировать двоичный файл будет сложно, вы всегда можете обратиться к человеку в середине(MitM) атакует, чтобы раскрыть секрет, как я показываю здесь для извлечения секрета, который скрыт в двоичном файле мобильного приложения с использованием собственных интерфейсов, JNI / NDK .
Чтобы защитить мобильное приложение от MitM, вы можете использовать Пиннинг сертификатов :
Пиннинг - это процесс связывания хоста с ожидаемым сертификатом X509 или открытым ключом.,Когда сертификат или открытый ключ известен или виден для хоста, сертификат или открытый ключ связывается или «закрепляется» на хосте.Если допустимо более одного сертификата или открытого ключа, программа хранит набор выводов (по словам Джона Ларимера и Кенни Рута из Google I / O talk).В этом случае объявленная идентификационная информация должна соответствовать одному из элементов в наборе.
Вы можете прочитать эту серию собственных статей, которые показывают, как применить закрепление сертификата кзащитить канал связи между вашим мобильным приложением и сервером API.
Если вы еще не знаете, закрепление сертификата также можно обойти с помощью таких инструментов, как Frida или xPposed.
Frida
Injectваши собственные сценарии в процессах черного ящика.Подключите любую функцию, следите за крипто-API или отслеживайте частный код приложения, исходный код не требуется.Отредактируйте, нажмите «Сохранить» и мгновенно увидите результаты.Все без шагов компиляции или перезапусков программы.
xPposed
Xposed представляет собой каркас для модулей, которые могут изменять поведение системы и приложений безкасаясь любых APK.Это здорово, потому что это означает, что модули могут работать для разных версий и даже ПЗУ без каких-либо изменений (если исходный код не был слишком изменен).Это также легко отменить.
Так что теперь вы можете быть удивлены, как я могу защитить от обхода закрепления сертификата?
Ну, это не легко, но возможно, с помощью мобильного приложенияРешение для аттестации.
Прежде чем мы продолжим его, я хотел бы сначала прояснить распространенное заблуждение среди разработчиков относительно WHO и WHAT , обращающихся к серверу API.
Разница между ВОЗ и ЧТО обеспечивает доступ к API-серверу
Чтобы лучше понять различия между WHO и ЧТО обращаются к APIсервер, давайте использовать эту картинку:
Канал предполагаемой связи представляет мобильное приложение, которое используется, как вы ожидаете, законным пользователем без каких-либо злонамеренных намерений, используя незашифрованную версиюмобильное приложение и общение напрямую с сервером API, не подвергаясь атаке человека посередине.
Фактический канал может представлять несколько различных сценариев, например, законный пользователь со злонамеренными намерениями, который может использовать переупакованную версию мобильного приложения, хакер, использующий подлинную версию мобильного приложения, в то время как человек в середине атакует его, чтобыпонять, как осуществляется связь между мобильным приложением и сервером API, чтобы иметь возможность автоматизировать атаки на ваш API.Возможны многие другие сценарии, но мы не будем перечислять здесь каждый.
Я надеюсь, что к настоящему времени у вас уже может быть подсказка, почему WHO и WHAT не одно и то же, но если нет, то это станет ясно через мгновение.
WHO является пользователем мобильного приложения, которое мы можем аутентифицировать, авторизовывать и идентифицировать несколькими способами, напримериспользуя OpenID Connect или потоки OAUTH2.
OAUTH
Обычно OAuth предоставляет клиентам «безопасный делегированный доступ» к ресурсам сервера от имени владельца ресурса,Он определяет процесс для владельцев ресурсов, чтобы разрешить сторонний доступ к своим ресурсам сервера без совместного использования своих учетных данных.Разработанный специально для работы с протоколом гипертекстовой передачи (HTTP), OAuth, по сути, позволяет выдавать маркеры доступа сторонним клиентам с помощью сервера авторизации с разрешения владельца ресурса.Затем третья сторона использует токен доступа для доступа к защищенным ресурсам, размещенным на сервере ресурсов.
OpenID Connect
OpenID Connect 1.0 представляет собой простой слой идентификации поверхпротокол OAuth 2.0.Это позволяет клиентам проверять подлинность конечного пользователя на основе аутентификации, выполняемой сервером авторизации, а также получать базовую информацию о профиле конечного пользователя взаимодействующим и REST-подобным образом.
Хотя аутентификация пользователя может сообщить серверу API, что WHO использует API, она не может гарантировать, что запросы исходили из ожидаемой WHAT исходной версии мобильного приложения..
Теперь нам нужен способ определить, ЧТО вызывает API-сервер, и здесь все становится сложнее, чем может подумать большинство разработчиков. WHAT - это то, что делает запрос к серверу API.Действительно ли это подлинный экземпляр мобильного приложения, или это бот, автоматизированный скрипт или злоумышленник, который вручную ковыряется на сервере API, используя такой инструмент, как Postman?
К вашему удивлению, вы можете обнаружитьчто это может быть один из законных пользователей, использующих переупакованную версию мобильного приложения или автоматизированный сценарий, который пытается геймифицировать и воспользоваться службой, предоставляемой приложением.
Ну, чтобы определить ЧТО , разработчики склонны прибегать к API-ключу, который обычно они жестко кодируют в коде своего мобильного приложения.Некоторые разработчики делают все возможное и вычисляют ключ во время выполнения в мобильном приложении, таким образом, он становится секретом времени выполнения в отличие от прежнего подхода, когда в код встроен статический секрет.
Запись выше-up был извлечен из статьи, которую я написал, под названием ПОЧЕМУ ВАШЕМУ МОБИЛЬНОМУ ПРИЛОЖЕНИЮ НУЖЕН КЛЮЧ API? , и которую вы можете прочитать полностью здесь , то есть первая статья всерия статей о ключах API.
Аттестация мобильных приложений
Использование решения для аттестации мобильных приложений позволит серверу API узнать ЧТО отправляет запросы, таким образомпозволяет отвечать только на запросы из подлинного мобильного приложения, отклоняя все другие запросы из небезопасных источников.
Роль службы аттестации мобильных приложений состоит в том, чтобы во время выполнения гарантировать, что ваше мобильное приложение не было взломано, не запущено на корневом устройстве и не является целью атаки MitM. Это делается путем запуска SDK в фоновом режиме, который будет взаимодействовать со службой, работающей в облаке, чтобы подтвердить целостность мобильного приложения и работающего устройства. Облачная служба также проверяет, что сертификат TLS, предоставленный мобильному приложению при рукопожатии с сервером API, действительно используется исходным и подлинным сервером API для мобильного приложения, а не сертификатом атаки MitM.
При успешной аттестации целостности мобильного приложения выдается кратковременный токен JWT, который подписывается с секретом, о котором знают только сервер API и служба аттестации мобильных приложений в облаке. В случае сбоя при аттестации мобильного приложения токен JWT подписывается секретом, которого сервер API не знает.
Теперь приложение должно отправлять при каждом вызове API токен JWT в заголовках запроса. Это позволит серверу API обслуживать запросы только в том случае, если он может проверить подпись и время истечения срока действия в токене JWT и отклонить их, если он не прошел проверку.
Как только секрет, используемый службой аттестации мобильных приложений, не известен мобильному приложению, его невозможно взломать во время выполнения, даже когда приложение подделано, работает на корневом устройстве или осуществляет связь через соединение, которое является целью человека в средней атаке.
Так что это решение работает в модели позитивного обнаружения без ложных срабатываний, таким образом, не блокируя законных пользователей, удерживая плохих парней в отсеках.
Какие у вас предложения по защите мира (реагирующих приложений) от надоедливых хакеров, когда они крадут ключи и используют их ненадлежащим образом?
Я думаю, вам следует по-настоящему использовать решение для аттестации мобильных приложений, которое вы можете использовать самостоятельно, если у вас есть для этого опыт, или вы можете использовать решение, которое уже существует в качестве решения SAAS на Approov (я работаю здесь), который предоставляет SDK для нескольких платформ, включая iOS, Android, React Native и другие. Для интеграции также потребуется небольшая проверка кода сервера API для проверки токена JWT, выпущенного облачной службой. Эта проверка необходима для того, чтобы сервер API мог решать, какие запросы обслуживать, а какие отклонять.
Резюме
Я хочу иметь возможность хранить ключи в приложении, чтобы я мог проверить пользователя и разрешить ему доступ к ресурсам на сервере. Однако я не знаю, каков наилучший план действий по обеспечению безопасности пользователей / бизнеса.
Не идите по этому пути хранения ключей в мобильном приложении, потому что, как вы уже знаете, благодаря вашим обширным исследованиям их можно обойти.
Вместо этого используйте решение для мобильной аттестации в сочетании с OAUTH2 или OpenID connect, которое можно связать с токеном аттестации мобильного приложения. Пример этой привязки токена можно найти в этой статье для проверки пользовательского утверждения полезной нагрузки в конечной точке /forms.
Пройдя лишнюю милю
Проект мобильной безопасности OWASP - 10 основных рисков
OWASP Mobile Security Project - это централизованный ресурс, предназначенный для предоставления разработчикам и командам безопасности ресурсов, необходимых для создания и поддержки безопасных мобильных приложений. В рамках проекта наша цель состоит в том, чтобы классифицировать риски для безопасности мобильных устройств и обеспечить средства управления развитием, чтобы уменьшить их воздействие или вероятность эксплуатации.