ОБЩЕСТВЕННЫЙ КЛЮЧ
Я внедряю закрепление SSL в нашем приложении для Android. Я закрепил 2 сертификата (текущий и резервный) на клиенте, вставив их в приложение.
Если вы прикрепляете открытый ключ, вам не нужно обновлять мобильное приложение каждый раз, когда сертификат поворачивается на сервере, как только вы подпишете его тем же открытым ключом, и вы сможете прочитать статью Руки На Mobile APi Security: закрепление клиентских подключений для более подробной информации о том, как это можно сделать:
Для работы в сети клиент Android использует библиотеку OKHttp. Если наш цифровой сертификат подписан центром сертификации, распознаваемым Android, для проверки сертификата можно использовать диспетчер доверия по умолчанию. Чтобы закрепить соединение, достаточно добавить имя хоста и хэш открытого ключа сертификата в построитель клиентов (). Посмотрите этот рецепт OKHttp для примера. Все сертификаты с одним и тем же именем хоста и открытым ключом будут соответствовать хэшу, поэтому такие методы, как ротация сертификатов, могут применяться без необходимости обновления клиента. Множественное имя хоста - кортежи с открытым ключом также могут быть добавлены в клиентский компоновщик ().
В случае, когда закрытый ключ, используемый для подписи сертификата, будет скомпрометирован, вы окажетесь в той же ситуации, которую пытаетесь решить сейчас, - это необходимость выпустить новое мобильное приложение, чтобы обновить то, чему вы доверяете приколоть Другими словами, открытому ключу больше нельзя доверять, поэтому сервер должен повернуть сертификат на сертификат, подписанный с помощью резервного ключа, который вы выпустили в своем мобильном приложении. Этот подход даст вам время для новой версии, которая удалит открытый ключ, используемый для подписи скомпрометированного сертификата, без блокировки всех ваших пользователей.
Вы всегда должны хранить резервные закрытые ключи в отдельных местах, чтобы, если один из них был взломан, вы не взломали все сразу, потому что в этом случае резервный пин-код, выпущенный с помощью мобильного приложения, бесполезен.
НЕ ДЕЛАЙТЕ ЭТОГО
Теперь я хочу иметь механизм для обновления этих сертификатов без необходимости развертывания обновления приложения в случае истечения срока действия сертификатов или взлома закрытого ключа. Как я могу это реализовать?
К сожалению, более безопасный метод для работы с скомпрометированным закрытым ключом - выпустить новое мобильное приложение, которое больше ему не доверяет. Любое удаленное решение, которое вы можете разработать для обновления сертификатов, откроет двери мобильных приложений для злоумышленников, чтобы заменить сертификаты, к которым вы прикрепляете.
Поэтому я советую не идти по этому пути, потому что вы будете стрелять себе в ногу легче, чем вы можете думать.
Одним из возможных решений, которое я вижу, является уведомление приложения. Я могу транслировать уведомления с новыми сертификатами и хранить их в клиенте. Есть ли проблема в этом подходе или есть лучший подход?
Пока мобильное приложение закрепляет соединение, его можно обойти, поэтому можно выполнить атаку MitM и получить новые сертификаты с сервера злоумышленников, а не с вашего сервера. Пожалуйста, прочитайте статью Проблема с закреплением , чтобы узнать, как ее обойти:
Открепление работает путем перехвата или перехвата вызовов функций в приложении во время его работы. После перехвата структура перехвата может изменить значения, переданные в или из функции. Когда вы используете библиотеку HTTP для реализации закрепления, функции, вызываемые библиотекой, хорошо известны, поэтому люди написали модули, которые специально перехватывают эти функции проверки, поэтому они всегда проходят независимо от фактических сертификатов, используемых в рукопожатии TLS. Аналогичные подходы существуют и для iOS.
Хотя закрепление сертификата можно обойти, тем не менее настоятельно рекомендуется его использовать, поскольку безопасность - это все уровни защиты, чем больше у вас сложностей, тем сложнее будет преодолеть все их ... Это не ново, если вы думаете,средневековых замков, они были построены с помощью этого подхода.
ВОЗМОЖНЫЙ ЛУЧШИЙ ПОДХОД
Но вы также просили о лучшем подходе:
Есть ли проблемы вэтот подход или есть какой-то лучший подход?
Как уже упоминалось, вы должны закрепить открытый ключ сертификата, чтобы избежать блокировки клиента при повороте сертификатов сервера.
Хотя я не могу указать вам лучший подход к работе с скомпрометированными закрытыми ключами, я могу указать, чтобы защитить закрепление сертификата от обхода средами интроспекции, такими как xPposed или Frida, но мы можем использовать метод аттестации мобильных приложений, который подтвердит подлинностьмобильного приложения.
Фрида
Внедрение собственных сценариев в процессы черного ящика.Подключите любую функцию, следите за крипто-API или отслеживайте частный код приложения, исходный код не требуется.Отредактируйте, нажмите «Сохранить» и мгновенно увидите результаты.Все без шагов компиляции или перезапусков программы.
xPposed
Xposed представляет собой каркас для модулей, которые могут изменять поведение системы и приложений безкасаясь любых APK.Это здорово, потому что это означает, что модули могут работать для разных версий и даже ПЗУ без каких-либо изменений (если исходный код не был слишком изменен).Также легко отменить.
Прежде чем мы углубимся в методику аттестации мобильных приложений, я хотел бы сначала прояснить обычное заблуждение среди разработчиков относительно WHO и ЧТО вызывает сервер API.
Разница между ВОЗ и ЧТО имеет доступ к серверу API
Чтобы лучше понять различия между ВОЗ и ЧТО обращаются к серверу API, давайте используем эту картинку:
Предполагаемый канал связи представляет мобильное приложение, используемое, как вы ожидали, законнымпользователь без каких-либо злонамеренных намерений, использующий нетронутую версию мобильного приложения и общающийся напрямую с сервером API, не подвергаясь атаке человека посередине.
Фактический канал может представлять несколько различных сценариев, например, законный пользователь сзлонамеренные намерения, которые могут использовать переупакованную версию мобильного приложения, хакер использует подлинную версию of мобильное приложение, в то время как человек в середине атакует его, чтобы понять, как осуществляется связь между мобильным приложением и сервером 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? , и которую вы можете прочитать полностью здесь , это первая статья в серии статей оКлючи API.
Аттестация мобильных приложений
Использование решения для аттестации мобильных приложений позволит серверу API узнать, ЧТО отправляет запросы, что позволяет отвечать только на запросы с подлинного мобильного телефона.приложение, отклоняя все другие запросы из небезопасных источников.
Роль аттестации мобильного приложения sСлужба должна гарантировать во время выполнения, что ваше мобильное приложение не было взломано или не запущено на корневом устройстве, запустив SDK в фоновом режиме, который будет взаимодействовать со службой, работающей в облаке, чтобы подтвердить целостность мобильного приложения и устройства.
При успешной аттестации целостности мобильного приложения выдается кратковременный токен JWT, который подписывается с секретом, о котором знают только сервер API и служба аттестации мобильных приложений в облаке.В случае сбоя при аттестации мобильного приложения токен JWT подписывается секретом, которого сервер API не знает.
Теперь приложение должно отправлять при каждом вызове API токен JWT в заголовках запроса.,Это позволит серверу API обслуживать запросы только тогда, когда он может проверить подпись и время истечения срока действия в токене JWT и отклонить их, если он не прошел проверку.
Как только секрет, используемый службой аттестации мобильных приложений, не являетсяизвестное мобильному приложению, невозможно выполнить его реинжиниринг во время выполнения, даже когда приложение подделано, работает на рутированном устройстве или осуществляет связь через соединение, являющееся целью для человека в средней атаке.
Таким образом, это решение работает в модели положительного обнаружения без ложных срабатываний, таким образом, не блокируя законных пользователей, удерживая плохих парней в отсеках.
Служба аттестации мобильных приложений уже существует как решение SAAS на Approov (я работаю здесь), который предоставляет SDK для нескольких платформ, включая iOS, Android, React Native и другие.Для интеграции также потребуется небольшая проверка кода сервера API для проверки токена JWT, выпущенного облачной службой.Эта проверка необходима для того, чтобы сервер API мог решать, какие запросы обслуживать, а какие отклонять.
ЗАКЛЮЧЕНИЕ
Поэтому я рекомендую вам переключиться, чтобы закрепить сертификаты открытым ключоми если вы хотите защитить себя от обхода закрепления сертификата и других угроз, вам следует разработать собственное решение для аттестации мобильных приложений или использовать его, готовое к работе по принципу «включай и работай».
Итак, в конце концов, решение, которое будет использоваться для защиты вашего мобильного приложения и сервера API, должно быть выбрано в соответствии со значением того, что вы пытаетесь защитить, и с юридическими требованиями для такого типа данных, как GDPRнормативные акты в Европе.
ВЫ ХОТИТЕ ПОЛУЧИТЬ ДОПОЛНИТЕЛЬНУЮ МИЛЮ?
Проект мобильной безопасности OWASP - 10 основных рисков
The OWASPMobile Security Project - это централизованный ресурс, предназначенный для того, чтобы предоставить разработчикам и командам безопасности ресурсы, необходимые для создания и поддержки защищенных мобильных приложений.В рамках проекта наша цель состоит в том, чтобы классифицировать риски для безопасности мобильных устройств и обеспечить средства контроля развития, чтобы уменьшить их влияние или вероятность эксплуатации.