Безопасность parse.com

Недавно я обнаружил, насколько полезен и удобен parse.com. Это действительно ускоряет разработку и предоставляет вам готовые базы данных для хранения всех данных, поступающих из вашего веб-приложения.

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

Но что, если кто-то сможет восстановить ключ из вашего приложения? Я попробовал это сам. Мне потребовалось 5 минут, чтобы найти секретный ключ из стандартного APK, и есть также возможность создать веб-приложение с секретным ключом, жестко закодированным в вашем источнике javascript где почти все могут видеть это.

Единственный способ защитить данные, которые я нашел, - это ACL (https://www.parse.com/docs/data), но это все равно означает, что каждый может иметь возможность вмешиваться в записываемые данные.

Может кто-нибудь просветить меня, пожалуйста?

Ответ 1

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

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

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

Ответ 2

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

а. Создайте вторичный объект, который содержит подмножество полей защищенных объектов.

б. Используя ACL, сделайте защищенный объект доступным только из соответствующего входа

с. Сделать общедоступным общедоступный объект

д. Напишите триггер, чтобы вторичный объект синхронизировался с обновлениями на первичный.

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

Ответ 3

Я сделал следующее.

Ограничить чтение/запись для общедоступных для всех классов. Единственный способ получить доступ к данным класса - через облачный код.
Убедитесь, что пользователь является зарегистрированным пользователем с использованием параметра request.user, и если пользовательский сеанс имеет значение null и если идентификатор объекта является допустимым.
Когда пользователь проверяется, я бы разрешил получение данных с помощью главного ключа.

Ответ 4

Просто держите жесткий контроль над параметрами глобальной безопасности уровня (создание класса клиента и т.д.), параметры безопасности на уровне классов (например, вы можете отключить удаление клиентов записями _Installation. Также часто отключается создание поля пользователя для все классы.), и самое главное, обратите внимание на списки ACL.

Обычно я использую триггеры beforeSave, чтобы убедиться, что ACL всегда правильные. Так, например, объекты _User находятся там, где находится адрес электронной почты для восстановления. Мы не хотим, чтобы другие пользователи могли видеть друг друга по электронной почте для восстановления, поэтому все объекты класса _User должны иметь только чтение и запись, только для пользователя (с общедоступным чтением false и public write false).

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

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

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

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

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