Meteor: SSR необходим для защиты административной части приложения?

У меня есть расширенная пользовательская модель в коллекции Meteor.users, из которой я публикую большинство полей для клиента. У каждого пользователя есть поле isAdmin, по умолчанию установленное на false.

Теперь у меня есть две проблемы, которые связаны:

How to make sure, components meant for admins can only be rendered, if the isAdmin field in the Meteor.users collection is set to true?
How to make sure, the isAdmin field on the Meteor.users collection cannot be modified from the clients console?

Относительно 1.

Я не решаюсь публиковать это поле для клиента и просто оценивать isAdmin на стороне клиента.

Я не уверен, есть ли какой-то хакерский способ через консоль просто изменить isAdmin таким образом, чтобы позволить отображать компонент (или его часть), предназначенный только для администраторов на клиент. Я мог представить, что это возможно, например, с Object.defineProperty().

Should I use server-side rendering to secure the admin part of my UI?

Относительно 2.

Рассмотрим первый абзац Редактирование профиля в этом статья о типичных ошибках. Это предполагает, что isAdmin можно легко изменить из клиента, вызвав Meteor.users.update(Meteor.userId(), {$set: {'isAdmin': true}}) из консоли.

Когда я запускаю его, войдя в свое приложение, я получаю update failed: Access denied.

Но даже официальная документация все же предлагает добавить

// Deny all client-side updates on the Lists collection
Lists.deny({
  insert() { return true; },
  update() { return true; },
  remove() { return true; },
});

в https://guide.meteor.com/security.html#разрешить-запретить

Существует отвечать, предполагающий, что достаточно просто проверить свойство isAdmin на стороне сервера, если вы убедитесь, что Meteor.methods только для сервера. Но он вообще не говорит о allow-deny, и ему 6 лет.

Can anyone tell, what truly is the case as of today?

security meteor meteor-accounts meteor-methods

31.05.2019 08:04

SQL Injection: Атаки в реальной жизни и как это вредит бизнесу

Один-единственный вредоносный запрос может нанести ущерб вашему бизнесу. Уязвимости вашего кода могут привести к:

Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Can anyone tell, what truly is the case as of today?

Я бы не стал прилагать слишком много усилий для защиты пользовательского интерфейса администратора на клиенте. Перенаправления на уровне маршрутизатора, когда isAdmin имеет значение false, должно быть достаточно.*

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

используйте ValidatedMethod из mdg:validated-methods для методов
напишите фабричную функцию для создания публикаций, похожих на mdg:validated-method, чтобы разрешить базовые проверки в стиле миксина
оба: проверьте правильность аргументов
оба: проверьте, существует ли пользователь
оба: проверьте, достаточно ли у пользователя ролей -> я рекомендую alanning:roles, так как он делает проверки уровня разрешений более безопасными, поскольку он проверяет наличие совпадения идентификаторов в выделенной коллекции, а не проверяет наличие флага в пользовательской коллекции (плюс это отделяет пользователей из ролей!)
Бросайте быстро и много: кидайте любую подозрительную нестыковку, старайтесь покрыть любое неопределенное состояние бросками ошибок.
ограничение скорости с использованием ddp-rate-limiter для каждого метода и публикации
напишите простую проверку работоспособности при запуске, которая гарантирует, что все методы и публикации ограничены по скорости, вы можете получить все зарегистрированные методы/публикации на сервере в Meteor.startup через Meteor.server.method_handlers и Meteor.server.publish_handlers
много писать тесты, особенно для методов, связанных с администрированием, и пробовать любой странный и сумасшедший ввод, который вы можете придумать, чтобы увидеть, будет ли он отклонен или вызовет какое-либо странное поведение (которого вы хотите избежать)

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

*если вы решите использовать рекомендуемый пакет alanning:roles, вам лучше также использовать его на клиенте для проверки ролей пользователя.

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

— 31.05.2019 17:04

31.05.2019 11:51