Управление сеансами одностраничных приложений и серверная часть Spring Security
У меня есть веб-приложение SPA и серверная часть Spring Boot. Я использую Spring Security для аутентификации входа в систему ldap и включения csrf. Теперь я немного не понимаю, как реализовать управление сеансами в SPA и обеспечить его безопасность.
Вопросы:
- Я сохраняю имя, фамилию и имя пользователя в файле cookie после успешного входа в систему ldap. Это нормально? Имя для входа и имя пользователя, поскольку они не являются учетными данными.
- Достаточно ли токена CSRF для защищенного SPA? Я немного застрял в принятии решения.
Надеюсь дать мне немного света/пути. Спасибо
ваш вопрос ясно говорит нам, что вы не проводили никакого поиска контента, чтобы узнать, что такое CSRF и что такое oauth2. but some blogs said csrf is enough если вы серьезно относитесь к этому утверждению, вам необходимо дать ссылку на источники. Предлагаю вам прочитать, что такое CSRF и какова его цель. Затем вы прочтете об oauth2 и его назначении, поскольку ясно, что этого не было сделано до того, как задать этот вопрос. Здесь начните читать portswigger.net/web-security/csrf и auth0.com/intro-to-iam/what-is-oauth-2
@JAsgarov, спасибо! я имею в виду, что после успешной аутентификации я хочу сохранить имя и фамилию пользователя во внешнем интерфейсе и поддерживать их вход в систему на протяжении всего сеанса. Я нашел эту ссылку на сайте freecodecamp freecodecamp.org/news/how-to-persist-a-logged-in-user-in-react
Ответы 1
Да, сеансовых файлов cookie + (на основе файлов cookie) защиты от CSRF достаточно для авторизации SPA на бэкэнде Spring.
Файлы cookie весенней сессии помечены знаком SameSite (как и должно быть). Таким образом, единственное, что нужно сделать, чтобы SPA был авторизован на серверной части на основе сеанса, это обслуживать оба файла с одним и тем же источником: браузер будет прикреплять файл cookie сеанса к каждому запросу REST от SPA к серверной части. Несколько вариантов:
- обслуживать оба через один и тот же обратный прокси (контейнер nginx Docker, k8s ingres,...)
- в случае, когда внутренней точкой входа является Spring Cloud Gateway, используйте маршрут для обслуживания ресурсов SPA.
- в случае, когда серверная часть рассматривается как единый сервис (монолит или единый фасад), обслуживайте активы SPA из статических ресурсов этого сервиса (используйте прокси-сервер WebPack или любую аналогичную функцию для вашей инфраструктуры SPA во время разработки)
Если вы перейдете на OAuth2 и будете следовать текущим рекомендациям для SPA , вам также понадобится защита от CSRF. @j-asgarov прав в своем комментарии: защита CSRF необходима, как только используются сеансы (а запросы между SPA и приложением Spring с oauth2Login авторизуются с помощью сеансов). Эта статья, которую я написал, может быть полезна для такого перехода (но вам, вероятно, не понадобится OAuth2, если все удостоверения хранятся в вашем LDAP, и вам не нужны такие функции, как SSO).
Привет. Спасибо за ответ, это именно то подтверждение, которое мне нужно. Да, все роли и идентификаторы указаны в LDAP. Судя по приведенным выше пунктам, я сейчас использую третий вариант. Я отмечу этот ответ. Еще раз спасибо!
Пожалуйста, задавайте по одному вопросу на каждый вопрос, иначе он станет слишком широким/сложным на ответ. Поэтому я дам очень краткие ответы. 1) Вероятно, вам не следует раскрывать какую-либо информацию в файлах cookie, информация о пользователе должна сохраняться в базе данных, и вы получаете доступ к ней, когда ваши пользователи проходят аутентификацию. 2) Токен CSRF смягчает одну конкретную проблему — CSRF. Вам это нужно, поскольку вы используете файлы cookie для управления сеансом (чтобы злоумышленник не отправлял электронное письмо людям с вредоносной скрытой ссылкой, которая инициирует действие на их компьютерах с использованием файлов cookie). Но это не единственная проблема. широкий, чтобы ответить