Как атаковать правила базы данных Firebase? - PullRequest
0 голосов
/ 30 января 2019

Я работаю с Firebase для приложения iOS.Я пытаюсь понять, насколько строгими должны быть мои правила, поэтому я пытаюсь напасть на них сам.Я думаю, что если я найду способы обойти действительно слабые правила (такие как .read и .write, разрешены или просто требуют авторизации), я смогу создать больше правил по мере необходимости.

Я довольно уверен вбезопасность моих учетных данных, поэтому злоумышленнику придется перехватывать трафик, используя прокси-сервер, и каким-то образом использовать свой токен авторизации для собственных вызовов в базу данных Firebase.Какой метод сможет использовать пользователь, чтобы получить свой токен авторизации (путем прослушивания трафика через прокси-сервер или иным образом) для совершения собственных вызовов в базу данных?Похоже, что Firebase SDK на iOS использует веб-сокеты, и инструменты для отслеживания веб-трафика (такие как Charles Proxy), похоже, не поддерживают лёгкий анализ веб-сокетов для iOS, поэтому я должен быть открытым без каких-либо правил базы данных в моем приложении?

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

Ответы [ 2 ]

0 голосов
/ 30 января 2019

В дополнение к тому, что сказал Дуг Стивенсон , стоит взглянуть на ограничение того, что пользователи могут записывать в базу данных с точки зрения структуры объекта.

Лично я использовал Firebase Bolt , который упрощает процесс.

Если вы хотите, чтобы пользователь записывал в свой объект учетной записи, который содержит firstName и emailAddress, вы можете написать разметку болта как:

type Accounts {
  emailAddress: String,
  firstName: String
}

path /accounts/{uid} is Accounts {
  create() { auth != null && auth.uid == uid; }
  update() { auth != null && auth.uid == uid; }
}

Это поможет сохранить ваши данные в чистоте иограничивает пользователя от нарушения логики.Если у них есть плоский .write доступ к их узлам, они могут удалять данные или создавать неструктурированные объекты, которые могут вызвать проблемы.Определение модели помогает защитить / поддерживать целостность базы данных.

0 голосов
/ 30 января 2019

Возможно, вы упускаете точку (немного).

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

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

...