Может ли пользователь изменить значение Redux / Mobx в Chrome, чтобы получить доступ к ограниченным представлениям?

Question

У меня есть приложение react + firebase. В коллекции пользователя у меня есть объект разрешений, где я отслеживаю, к чему у пользователя есть доступ. Затем в моем приложении для реагирования у меня есть следующее:

  // Login component
    const userRecord = await Firebase.login(email,password)
    store.user = await this.fetchUser(userRecord.uid)

Для представлений только для администратора я помещаю их в withAuthorization HO C, где я проверяю store.user.permissions.admin

  // Not exactly this, but this is the general idea
  {store.user.permissions.admin && <RestrictedView />

Мой вопрос: может ли пользователь изменить значение разрешений в chrome, чтобы получить доступ к ограниченным представлениям? Если да, то есть ли лучший подход? В конечном итоге я могу использовать customClaims, но пока хотел бы использовать вышеуказанное.

Заранее спасибо!

Answer 1

Всегда предполагайте, что злоумышленник имеет полный контроль над браузером.

Обычно, если вы хотите, чтобы ваше приложение было защищено от вредоносных объектов, безопасность его должна исходить от сервера. Сделайте токены авторизации / предъявителя или схему Cook ie, которая может быть проверена вашим сервером (например, https://jwt.io/). Затем разрешите отправку данных только тем пользователям, которым вы хотите, на основе этой информации. Безопасность / проверка во внешнем интерфейсе больше касается того, чтобы пользователи случайно не испортили вещи.

Пользователь имеет полную возможность изменять любой HTML / CSS / JS, который у вас есть в браузере, с помощью различных dev-tools.

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

All React состояние может быть довольно легко изменено с помощью инструментов разработки React. Если вы используете redux, у вас могут быть настроены инструменты разработки redux.

В firebase есть целый раздел по безопасности в документы Настройте данные, которые будут стоять за вашими RestrictedView s, чтобы они требовали требуемых уровней аутентификации. Убедитесь, что firebase обеспечивает безопасность вашего приложения. Раздел о небезопасных правилах также является хорошим местом, чтобы начать читать о том, что firebase может сделать для вас и как настроить свои правила безопасности .

Дополнительная литература:

OW ASP Top Ten (2017) Broken Access Control (жирный шрифт добавлен для выделения)

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

• За исключением publi c ресурсы, по умолчанию запрещены.

• Реализуйте механизмы управления доступом один раз и повторно используйте их во всем приложении, включая минимизацию использования CORS.

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

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

• Отключите список каталогов веб-сервера и убедитесь, что метаданные файлов (например, git) и файлы резервных копий отсутствуют в корневых веб-сайтах.

• Регистрировать сбои управления доступом, при необходимости предупреждать администраторов (например, о повторных сбоях).

• API ограничения скорости и доступ к контроллеру для минимизации вреда от автоматизированных инструментов атаки.

• Токены JWT должны стать недействительными на сервере после выхода из системы. Разработчики и сотрудники QA должны включать функциональный блок управления доступом и интеграционные тесты.

Понимание безопасности React Frontend

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

Далее в этой статье:

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

Вы делаете это точно так же, как и предполагали, - вы создаете переменную, устанавливаете ее значение true только для администраторов, и после прохождения проверки показываете контент только для администратора.

«Хорошо, это совсем не безопасно - каждый может go перейти на страницу администратора и удалить все!» вы кричите.

Честно, но только если вы плохо реализуете свое приложение. Внешняя часть не должна заботиться о действительности предоставленных учетных данных. Он всегда должен принимать данные как «истинные» и просто отображать все переданные данные.

Это внутреннее задание для выполнения этой проверки!