Запретить работу базы данных Firebase (или аутентификации), если APK SHA не соответствует SHA в консоли Firebase?

#android #firebase #firebase-realtime-database

#Android #firebase #firebase-realtime-database

Вопрос:

Сценарий: пользователь может взять мой APK, декомпилировать его, изменить код и запустить. Что помешало бы им изменять совершенно допустимые вызовы моей базы данных Firebase в реальном времени, но вместо этого использовать бессмысленные данные? Или делает что-то вредоносное? Обратите внимание, это не касается правил чтения / записи, поскольку узлы БД, которые они читают / записывают, будут разрешены, но измененный код просто выполнял бы эти действия способом, который нежелателен для получения базой данных при обычных обстоятельствах.

Я чувствую, что отпечаток SHA-1 в настройках моего проекта в Firebase console будет ответом на предотвращение доступа к Firebase любых неправильно подписанных APK-файлов, верно?

введите описание изображения здесь

Я добавил к нему DEBUG SHA-1 и попробовал две вещи:

  1. Я не загружал недавно обновленный google-services.json, все равно запустил свое приложение с подписью DEBUG
  2. Я скомпилировал релизную версию своего приложения и запустил ее (очевидно, с другой подписью)

В обоих случаях база данных Firebase все еще функционировала …? Итак, в чем смысл отпечатка SHA? Как мне в принципе переключить параметр «если этот APK подписан неправильно, не обращаться к базе данных»?

Комментарии:

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

2. Как бы правила запрещали кому-либо, например, onClick () рассылать спам из 100 сообщений в чат, в то время как код на стороне клиента никогда этого не допустит. Или что-то вроде отсоединения некоторых ожидаемых пакетных записей в одном вызове updateChildren() на узле. Это не обязательно «вредоносный» код, а скорее изменение ожидаемого, разрешенного правилами нормального поведения в виде боттинга.

3. Я предлагаю выполнить некоторые поисковые запросы в Интернете, чтобы найти общие решения для конкретных ограничений, которые вы хотите применить. Если у вас есть конкретный вопрос о конкретном ограничении, которое вы пытаетесь реализовать, отправьте вопрос, объясняющий эту конкретную проблему.

4. Вот один, который кажется проблематичным. У меня есть /rooms/ node с объектами Room в нем. Например, когда пользователь присоединяется к комнате, я хотел бы добавить UID пользователя в список «joinedMembers» комнаты. Это означает, что в правилах БД пользователь будет иметь доступ на ЗАПИСЬ как минимум к списку узлов комнаты «joinedMembers». Что мешает пользователю изменять APK, чтобы вместо добавления своего UID при выполнении этого кода они добавляли чужой UID? Или просто бессмысленные цифры?

5. Ваши правила безопасности предотвратят это в соответствии с вашей спецификацией. Я рекомендую изучить их и начать получать опыт их написания. Ничто не собирается писать эти правила для вас.