Безопасность

Проверка приложений Firebase: новое измерение в безопасности приложений

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

Почему проверка приложений?

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

Проверка приложений предназначена для защиты разработчика приложений

Это проблема, которую пытается решить App Check. В то время как правила проверки подлинности и безопасности Firebase защищают пользователей приложений, обеспечивая проверку подлинности пользователей, проверка приложений предназначена для защиты разработчика приложения, обеспечивая проверку подлинности приложения.

Как это работает?

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

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

Похоже, это немного, но как разработчику вам не нужно много делать, чтобы начать использовать Firebase App Check. Большую часть тяжелой работы выполняют SDK Firebase и серверные службы. В большинстве случаев все, что вам нужно сделать, это настроить несколько вещей в консоли Firebase и добавить немного нового кода в свое приложение. Листинг 1 показывает весь дополнительный код, который вам нужно написать, чтобы добавить поддержку проверки приложений с помощью reCAPTCHA v3 в веб-приложение.

У вас также есть возможность включить проверку приложений в своем приложении без активации контроля доступа проверки приложений в серверных службах Firebase (т. Е. Серверные службы будут продолжать принимать все запросы в обычном режиме). Это полезно, поскольку принудительное применение контроля доступа к проверке приложений может нарушить работу старых версий вашего приложения. Консоль Firebase предоставляет подробные метрики об источниках вашего внутреннего трафика: она показывает, сколько запросов пришло от подлинных клиентов, а сколько - от устаревших, неизвестных или потенциально вредоносных клиентов. Вы можете активировать принудительное управление доступом на основе этой информации. В большинстве случаев вы, по крайней мере, захотите подождать, пока подавляющее большинство ваших пользователей обновится до последней версии вашего приложения с включенной функцией проверки приложений, прежде чем начинать принудительное применение.

Обратите внимание, что уровень безопасности, обеспечиваемый проверкой приложений, зависит от поставщика аттестации. Такие провайдеры, как reCAPTCHA v3, могут только подтвердить, что данный запрос поступил из подлинного экземпляра вашего приложения. Но такие поставщики, как App Attest и SafetyNet, могут пойти дальше и также подтвердить, исходит ли данный запрос от устройства, не подвергшегося вмешательству.

Защита собственных серверных служб с помощью проверки приложений

Firebase App Check помогает защитить ваши ресурсы базы данных в реальном времени, хранилища Firebase и облачных функций. Однако, если ваше приложение зависит от каких-либо собственных серверных служб, вы также можете защитить эти службы с помощью проверки приложений. Например, предположим, что вы реализовали и развернули серверную службу, показанную в листинге 2 по адресу api.myserver.com.

Здесь callExternalService() может быть вызов API третьей стороне, за которую вам выставлен счет. Вы можете вызвать указанную выше службу из своего веб-приложения, как показано в листинге 3.

Как и большинство служб, доступных через Интернет, ваша служба в api.myserver.com также уязвима для широкого спектра фишинговых и биллинговых атак. Злоумышленник может затопить вашу конечную точку ненужным трафиком, что замедлит работу вашего сервиса и понесет большой счет из-за всех дополнительных вызовов callExternalService(). Вы можете защитить свой сервис от этого типа атак с помощью Firebase App Check. Проверка приложений может помочь вам убедиться, что все входящие запросы к вашей службе исходят из вашего подлинного веб-приложения и больше нигде. Вот как.

Вы можете защитить свой сервис от атак с помощью Firebase App Check

Во-первых, вам нужно изменить клиентское приложение так, чтобы оно отправляло токен проверки приложения вместе с запросами, сделанными вашей конечной точке сервера. Листинг 4 показывает, как получить токен проверки приложения из Firebase Web SDK и включить его в исходящий запрос в качестве заголовка.

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

Затем мы модифицируем реализацию серверной службы, чтобы проверить токен проверки приложений с помощью Firebase Admin SDK. Листинг 5 показывает, как это можно сделать.

По промежуточного слоя appCheckVerification выполняется до нашей реальной бизнес-логики. Это промежуточное ПО извлекает токен проверки приложений из заголовка запроса и проверяет его с помощью Admin SDK. Если токен признан действительным, мы продолжаем обработку запроса. Если токен отсутствует или недействителен, мы останавливаем обработку запроса и отправляем ответ 401 Unauthorized.

Этот простой механизм можно использовать в любой серверной службе, от которой зависят ваши приложения Firebase. В результате ваша серверная служба будет ограничена только вашими подлинными приложениями и никем другим. Проверка токена App Check - довольно эффективная операция, и ее можно включить в большинство процессов обработки запросов к бэкэнду. Объекты JWKS, необходимые для выполнения проверки, загружаются один раз и кэшируются Admin SDK на несколько часов за раз. Поэтому после первоначального холодного запуска SDK проверка токена App Check может выполняться полностью как локальная операция без дополнительных RPC.

Почему это кажется знакомым?

Если вы использовали Firebase Auth в прошлом и реализовали серверные службы, требующие проверки идентификатора токена, вы увидите здесь некоторые параллели. Концептуально проверка токена ID и проверка токена App Check очень похожи. Но они служат совершенно разным целям.

Проверка токена Firebase Auth ID - это способ установить личность пользователя и ограничить службу определенной группой аутентифицированных пользователей. Проверка токена проверки приложений - это способ установить личность приложения и ограничить службу определенным набором приложений. В зависимости от вашего варианта использования вам может потребоваться один или оба в ваших серверных службах. Вот несколько примеров использования:

  • Только пользователи с ролью moderator должны иметь доступ к моей службе. Меня не волнует, какие приложения они используют для взаимодействия с моей службой: это случай аутентификации пользователя .
  • Только пользователи моего приложения XYZ должны иметь доступ к моему сервису. Меня не волнует, какие роли и разрешения у них есть в приложении: это случай аутентификации app .
  • Только пользователи с ролью moderator из моего приложения XYZ должны иметь доступ к моему сервису. Не модераторы в XYZ и модераторы, вошедшие в приложения, отличные от XYZ, не допускаются: здесь требуется аутентификация как user, так и app .

Заключение

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