Защита от AngularJS при аутентификации

Question

Мы разрабатываем систему с использованием AngularJS и PHP. У меня есть некоторые проблемы с безопасностью по вопросу аутентификации. Я написал базовую аутентификацию, основанную на нескольких разных примерах в Интернете (я только начал изучать Angular), которая использует базу данных через вызовы API REST. На некоторых маршрутах он проверяет информацию о пользователе существует, прежде чем он создает обещание, но у меня есть несколько вопросов:

• Can информация о сеансе храниться в $window.sessionStorage или $cookieStorage без клиента будучи в состоянии изменить эти значения или должны Я держу их на стороне сервера с PHP $_SESSION и извлекаю их оттуда, никогда не сохраняя их нигде в JS? Информация сессии может содержать uid, роль, адрес электронной почты и имя

• Могу ли я сохранить значение, например, $rootScope.role или $scope.role, если у клиента нет возможности изменить это значение? Скажем, например, у нас есть несколько уровней учетных записей пользователей, где супер-админ является самым высоким. Если я создам маршрут с разрешением, который будет проверять уровень $rootScope.role, может ли начинающий изменить значение $rootScope.role на супер-админ, получая доступ к ограниченным разделам бэкэнд?

• Должен ли я выполнять проверку GET/сеанса на каждом маршруте, который получает данные $_SESSION, чтобы действительно убедиться, что эти данные остаются нетронутыми?

• Или я просто параноик?

Answer 1

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

Функции, связанные с безопасностью, должны оставаться на бэкэнд, среде, которую вы настроили и контролируете.

Может ли начинающий идти изменить значение $ rootScope.role для супер-администратора, получающего доступ к ограниченным разделам бэкэнд?

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

Answer 2

Большой вопрос! Передняя защита требует взаимодействия браузера и вашего сервера.

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

Запросы API обычно аутентифицируются с помощью файла cookie. Файл cookie обычно содержит идентификатор сеанса, который указывает на строку в вашей базе данных, которая содержит информацию авторизации (то есть, что пользователю разрешен доступ). Пользователь может получить этот файл cookie, войдя в систему (представляя жесткие учетные данные, такие как имя пользователя и пароль).

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

В любом случае вы хотите установить флаг HttpOnly в файл cookie, когда ваш сервер отправляет файл cookie в браузер. Это не позволит среде JavaScript читать cookie, это хорошая мера безопасности для вас против атак XSS.

Вам также необходимо защитить себя от атак CSRF. Это ситуация, когда другой веб-сайт может инициировать запрос GET или POST для вашего API, и это отправит cookie аутентификации. Вы можете предотвратить это, создав еще один файл cookie, который НЕ имеет флаг HttpOnly, и сохраняя в нем случайное значение. Среда JS должна привязывать это значение к любому запросу, как правило, в качестве настраиваемого HTTP-заголовка. Затем ваш сервер утверждает, что это значение связано с сеансом или токеном.

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

Token Based Authentication for Single Page Apps (SPAs)

https://stormpath.com/blog/build-secure-user-interfaces-using-jwts/

Отказ от ответственности: Я работаю в Stormpath и предоставляет безопасное, размещенное решение для управления пользователями для любого приложения, включая Angular! См. https://docs.stormpath.com, чтобы узнать больше и найти SDK для своего сервера.