Что, если кто-то украл ваш GoogleInfo.plist и все время создает пользователя Firebase? [Firestore, Firebase Auth, правила безопасности] - PullRequest
Новая
       14

Что, если кто-то украл ваш GoogleInfo.plist и все время создает пользователя Firebase? [Firestore, Firebase Auth, правила безопасности]

1 голос
/ 17 июня 2020

У меня серьезный вопрос. Я разрабатываю правила безопасности для своей базы данных Firestore. Что, если кто-то декомпилировал мое приложение, украл GoogleInfo.plist, добавил этот файл в свой проект и создал с ним несколько учетных записей? Я имею в виду, что в правилах безопасности вы должны: 

allow create: if request.auth != null;

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

Как решить и защитить это?

Существуют ли другие варианты, например, вход в систему с настраиваемым полем:

Я создаю идентификатор документа.

и поэтому мы проверяем правила Firestore: 

match /document/{myDOC}
allow write: if request.auth.code == myDOC;

Итак, я имею в виду, могу ли я установить дополнительную информацию в запрос моего приложения и проверить, равна ли дополнительная информация myDOC;

Спасибо !!

Ответы [ 2 ]

1 голос
/ 17 июня 2020

Это все работает по замыслу. В GoogleInfo.plist нет информации о «безопасности». Он просто содержит данные, которые инструктируют Firebase SDK о том, как найти ваш проект и его ресурсы. Без этих данных ваше приложение ничего бы не узнало о вашем проекте. напишите, какие документы, как это предлагается в документации .

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

См. Также: Безопасно ли предоставлять Firebase apiKey для publi c?

0 голосов
/ 17 июня 2020

https://firebase.google.com/docs/auth/admin/custom-claims

Firebase Admin SDK позволяет вам определять настраиваемые атрибуты для учетных записей пользователей. 

admin.auth().setCustomUserClaims(uid, {admin: true}).then(() => {
  // The new custom claims will propagate to the user's ID token the
  // next time a new one is issued.
});

Когда вы пишете свои правила, это возможно чтобы проверить эти настраиваемые атрибуты. 

{
  "rules": {
    "adminContent": {
      ".read": "auth.token.admin === true",
      ".write": "auth.token.admin === true",
    }
  }
}

Но, как указано в документации, вы должны учитывать следующие моменты:

  1. Используйте настраиваемые утверждения для хранения данных только для управления доступом пользователей . Все остальные данные должны храниться отдельно в базе данных реального времени или другом хранилище на стороне сервера.
  2. Размер настраиваемых требований ограничен. Передача пользовательской полезной нагрузки утверждений размером более 1000 байт вызовет ошибку.
...