ЗАКРЫТИЕ ОТКРЫТОГО КЛЮЧА

Я реализую закрепление SSL в нашем приложении для Android. Я закрепил 2 сертификата (текущий и резервный) на клиенте, внедрив их в приложение.

Если вы привязываетесь к открытому ключу, вам не нужно обновлять мобильное приложение каждый раз при смене сертификата на сервере, поскольку вы подписываете его одним и тем же открытым ключом, и вы можете прочитать статью Hands On Mobile API Security: Pinning Client Connections, чтобы узнать больше о том, как это может быть сделано:

Для работы в сети клиент Android использует библиотеку OKHttp. Если наш цифровой сертификат подписан ЦС, признанным Android, для проверки сертификата можно использовать диспетчер доверия по умолчанию. Для закрепления соединения достаточно добавить имя хоста и хэш открытого ключа сертификата в client builder(). См. этот рецепт OKHttp для примера. Все сертификаты с одинаковым именем хоста и открытым ключом будут соответствовать хешу, поэтому можно использовать такие методы, как ротация сертификатов, без необходимости обновлений клиента. Множественное имя хоста — кортежи с открытым ключом также могут быть добавлены в client builder().

В ситуации, когда закрытый ключ, используемый для подписи сертификата, скомпрометирован, вы окажетесь в той же ситуации, которую вы пытаетесь решить сейчас, то есть необходимо выпустить новое мобильное приложение, чтобы обновить то, к чему вы доверяете. Другими словами, открытому ключу больше нельзя доверять, поэтому сервер должен заменить сертификат сертификатом, подписанным резервным открытым ключом, который вы выпустили в своем мобильном приложении. Этот подход даст вам время для новой версии, которая удалит открытый ключ, используемый для подписи скомпрометированного сертификата, без блокировки всех ваших пользователей.

Вы всегда должны хранить резервные закрытые ключи в отдельных местах, чтобы, если один из них был скомпрометирован, вы не скомпрометировали все сразу, потому что в этом случае выпуск резервного PIN-кода с мобильным приложением бесполезен.

НЕ ДЕЛАЙТЕ ЭТОГО

Теперь я хочу иметь механизм для обновления этих сертификатов без необходимости развертывания обновления приложения в случае, если срок действия сертификатов истек или закрытый ключ скомпрометирован. Как я могу это реализовать?

К сожалению, более безопасный способ справиться со скомпрометированным закрытым ключом — выпустить новое мобильное приложение, которое больше ему не доверяет. Любое удаленное решение, которое вы можете придумать для обновления сертификатов, откроет двери мобильного приложения для злоумышленников, чтобы заменить сертификаты, к которым вы привязываетесь.

Так что мой совет — не идти по этому пути, потому что вы прострелите себе ногу легче, чем вы думаете.

Одно из возможных решений, которое я вижу, — это уведомление приложения. Я могу транслировать уведомление с новыми сертификатами и хранить их в клиенте. Есть ли проблема в этом подходе или есть лучший подход?

Пока мобильное приложение имеет закрепленное соединение, его можно обойти, таким образом можно выполнить атаку MitM и получить новые сертификаты с сервера злоумышленников, а не с вашего сервера. Прочтите статью Проблема с фиксацией, чтобы узнать, как ее обойти:

Открепление работает путем перехвата или перехвата вызовов функций в приложении во время его работы. После перехвата инфраструктура перехвата может изменить значения, передаваемые в функцию или из нее. Когда вы используете библиотеку HTTP для реализации закрепления, функции, вызываемые библиотекой, хорошо известны, поэтому люди написали модули, которые специально перехватывают эти функции проверки, чтобы они всегда проходили независимо от фактических сертификатов, используемых в рукопожатии TLS. Подобные подходы существуют и для iOS.

Несмотря на то, что закрепление сертификата можно обойти, все же настоятельно рекомендуется его использовать, потому что безопасность — это все уровни защиты, и чем их больше, тем сложнее будет преодолеть их все... В этом нет ничего нового, если вы думаете о средневековье. замки, они были построены с таким подходом.

ВОЗМОЖНО ЛУЧШИЙ ПОДХОД

Но вы также попросили лучшего подхода:

Есть ли проблема в этом подходе или есть лучший подход?

Как уже упоминалось, вы должны привязать открытый ключ сертификата, чтобы избежать блокировки клиента при смене сертификатов сервера.

Хотя я не могу указать вам лучший подход к работе со скомпрометированными закрытыми ключами, я могу указать, что для защиты закрепления сертификата от обхода с помощью фреймворков самоанализа, таких как xPosed или Frida, мы можем использовать метод аттестации мобильного приложения, который подтвердит подлинность мобильного приложения.

Фрида

Внедряйте собственные скрипты в процессы черного ящика. Подключайте любую функцию, следите за криптографическими API или отслеживайте код частного приложения, исходный код не требуется. Отредактируйте, нажмите «Сохранить» и сразу же увидите результаты. Все без шагов компиляции или перезапуска программы.

xPosed

Xposed — это фреймворк для модулей, которые могут изменить поведение системы и приложений, не затрагивая никаких APK. Это здорово, потому что это означает, что модули могут работать для разных версий и даже ПЗУ без каких-либо изменений (при условии, что исходный код не был слишком сильно изменен). Это также легко отменить.

Прежде чем мы углубимся в метод аттестации мобильных приложений, я хотел бы сначала развеять распространенное среди разработчиков заблуждение относительно КТО и ЧТО вызывает сервер API.

Разница между КТО и ЧТО заключается в доступе к серверу API

Чтобы лучше понять разницу между КТО и ЧТО обращаются к серверу API, воспользуемся этим рисунком:

Предполагаемый коммуникационный канал представляет собой мобильное приложение, используемое, как вы ожидали, законным пользователем без каких-либо злонамеренных намерений, использующее незащищенную версию мобильного приложения и взаимодействующее напрямую с сервером API без нападения человека посередине.

Фактический канал может представлять несколько различных сценариев, например, законный пользователь со злыми намерениями, который может использовать переупакованную версию мобильного приложения, хакер, использующий подлинную версию мобильного приложения, в то время как человек посередине атакует его, чтобы понять, как связь между мобильным приложением и сервером API осуществляется для того, чтобы иметь возможность автоматизировать атаки на ваш API. Возможны и многие другие сценарии, но мы не будем здесь перечислять каждый из них.

Я надеюсь, что к настоящему времени вы, возможно, уже поняли, почему КТО и ЧТО не одно и то же, но если нет, то через мгновение станет ясно.

WHO — это пользователь мобильного приложения, которого мы можем аутентифицировать, авторизовать и идентифицировать несколькими способами, например с помощью потоков OpenID Connect или OAUTH2.

OAUTH

Как правило, OAuth предоставляет клиентам безопасный делегированный доступ к ресурсам сервера от имени владельца ресурса. Он определяет процесс, с помощью которого владельцы ресурсов разрешают доступ третьих лиц к своим ресурсам сервера без предоставления своих учетных данных. Разработанный специально для работы с протоколом передачи гипертекста (HTTP), OAuth, по сути, позволяет серверу авторизации выдавать токены доступа сторонним клиентам с одобрения владельца ресурса. Затем третья сторона использует токен доступа для доступа к защищенным ресурсам, размещенным на сервере ресурсов.

Подключение OpenID

OpenID Connect 1.0 — это простой уровень идентификации поверх протокола OAuth 2.0. Это позволяет клиентам проверять личность конечного пользователя на основе аутентификации, выполняемой сервером авторизации, а также получать базовую информацию о профиле конечного пользователя совместимым и REST-подобным образом.

Хотя проверка подлинности пользователя может сообщить серверу API, КТО использует API, она не может гарантировать, что запросы исходят из ЧЕГО вы ожидаете, т. е. из исходной версии мобильного приложения.

Теперь нам нужен способ определить, ЧТО вызывает сервер API, и здесь все становится сложнее, чем может показаться большинству разработчиков. ЧТО — это то, что делает запрос к серверу API. Действительно ли это подлинный экземпляр мобильного приложения или это бот, автоматизированный скрипт или злоумышленник, который вручную копается в сервере API, используя такой инструмент, как Postman?

К вашему удивлению, вы можете в конечном итоге обнаружить, что это может быть один из законных пользователей, использующих переупакованную версию мобильного приложения или автоматизированный скрипт, который пытается геймифицировать и воспользоваться услугой, предоставляемой приложением.

Приведенный выше текст взят из написанной мной статьи под названием ПОЧЕМУ ВАШЕМУ МОБИЛЬНОМУ ПРИЛОЖЕНИЮ НУЖЕН КЛЮЧ API?, которую вы можете полностью прочитать здесь, это первая статья из серии статей о ключах API.

Аттестация мобильного приложения

Использование решения для аттестации мобильных приложений позволит серверу API узнать, ЧТО отправляет запросы, что позволит отвечать только на запросы от подлинного мобильного приложения, отклоняя все остальные запросы из небезопасных источников.

Роль службы аттестации мобильных приложений заключается в том, чтобы во время выполнения гарантировать, что ваше мобильное приложение не было изменено или не работает на корневом устройстве, путем запуска SDK в фоновом режиме, который будет связываться со службой, работающей в облаке, для подтверждения целостность мобильного приложения и устройства работает.

При успешной аттестации целостности мобильного приложения краткосрочный токен JWT выпускается и подписывается секретом, который известен только серверу API и службе аттестации мобильных приложений в облаке. В случае сбоя при аттестации мобильного приложения токен JWT подписывается секретом, который не известен серверу API.

Теперь приложение должно отправлять с каждым вызовом API токен JWT в заголовках запроса. Это позволит серверу API обслуживать запросы только тогда, когда он может проверить подпись и время истечения срока действия в токене JWT, и отклонить их, если проверка не пройдена.

Если секрет, используемый службой аттестации мобильных приложений, не известен мобильному приложению, его невозможно реконструировать во время выполнения, даже если приложение взломано, работает на корневом устройстве или обменивается данными через соединение, которое является Цель атаки Человека посередине.

Таким образом, это решение работает в модели положительного обнаружения без ложных срабатываний, таким образом, не блокируя законных пользователей и удерживая плохих парней в страхе.

Служба аттестации мобильных приложений уже существует в виде решения SAAS по адресу Approov(я работаю здесь), которое предоставляет SDK для нескольких платформ, включая iOS, Android, React Native и другие. Для интеграции также потребуется небольшая проверка в коде сервера API для проверки токена JWT, выданного облачной службой. Эта проверка необходима для того, чтобы сервер API мог решить, какие запросы обслуживать, а какие отклонять.

ВЫВОД

Поэтому я рекомендую вам переключиться на закрепление сертификатов с помощью открытого ключа, и если вы хотите защититься от обхода закрепления сертификатов и других угроз, вам следует разработать собственное решение для аттестации мобильных приложений или использовать уже готовое к подключению. играть.

Итак, в конце концов, решение для защиты вашего мобильного приложения и сервера API должно быть выбрано в соответствии с ценностью того, что вы пытаетесь защитить, и юридическими требованиями для этого типа данных, такими как правила GDPR в Европе. .

ВЫ ХОТИТЕ ПРОЙТИ ДОПОЛНИТЕЛЬНУЮ МИЛЬ?

Проект OWASP Mobile Security — 10 основных рисков

Проект OWASP Mobile Security — это централизованный ресурс, предназначенный для предоставления разработчикам и специалистам по безопасности ресурсов, необходимых им для создания и обслуживания безопасных мобильных приложений. В рамках проекта наша цель состоит в том, чтобы классифицировать риски безопасности мобильных устройств и обеспечить контроль разработки, чтобы уменьшить их влияние или вероятность использования.