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

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

1 голос
/ 31 мая 2019

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

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

  1. Какубедитесь, что компоненты, предназначенные для администраторов, могут отображаться только в том случае, если для поля isAdmin в коллекции Meteor.users установлено значение true?

  2. Какчтобы убедиться, что поле isAdmin в коллекции Meteor.users нельзя изменить с консоли клиента?

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

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

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

Должен ли я использовать server-side rendering для защиты административной части моего пользовательского интерфейса?

Относительно 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#allow-deny

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

Кто-нибудь может сказать, что на самом деле происходит сегодня?

1 Ответ

2 голосов
/ 31 мая 2019

Кто-нибудь может сказать, что на самом деле происходит на сегодняшний день?

Я бы не стал прилагать слишком много усилий для обеспечения безопасности интерфейса администратора на клиенте.Перенаправление уровня маршрутизатора, когда 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, лучше использовать его на клиенте, чтобыпроверьте роли пользователя.

...