Почему новый сеанс создается до того, как я войду в систему?

1

Я создал веб-приложение, использующее приглашение входа Spring Security (3.2). Я запускаю приложение в Tomcat 7. Я использую диспетчер Tomcat для мониторинга сеансов. Это приложение Vaadin, использующее сервлет Vaadin. Нет страниц JSP.

Теперь...

  1. У меня есть недавно запущенный Tomcat со свежей развернутой версией.war.
  2. Я открываю веб-браузер и вводим URL-адрес приложения и нажимаю Enter, который приземляет меня на странице входа в указанное приложение.
  3. Я вижу в менеджере Tomcat, что 1 сеанс был создан. Заметьте, что я даже не пробовал войти в систему.
  4. Я закрываю вкладку браузера приложения и сам браузер и повторно открываю его (т.е. Эффективно удаляя любые данные сеанса) и снова вводим URL-адрес и нажимаю клавишу ввода.
  5. В диспетчере Tomcat я вижу, что был создан еще один сеанс. Сейчас в общей сложности 2 сеанса. Обратите внимание, что я до сих пор даже не пытался войти в систему.

Является ли это предполагаемым поведением (предотвращение какой-либо атаки фиксации сеанса) или я просто настроил что-то неправильно?

Теги:
spring-security
spring
tomcat
session

2 ответа

5
Лучший ответ

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

Более длинная версия заключается в том, что процесс входа в систему (при условии успешной аутентификации) будет что-то вроде этих строк:

  1. Запросы агента пользователя /some/secure/page
  2. Проверка контейнера для аутентифицированного пользователя
  3. Пользователь не аутентифицирован, поэтому контейнер начинает процесс входа в систему
  4. Контейнер создает сеанс
  5. Контейнер добавляет URL целевой страницы (/some/secure/page) в сеанс
  6. Контейнер перенаправляет пользователя на страницу входа в систему
  7. Пользователь регистрируется в
  8. Контейнер проверяет учетные данные
  9. Контейнер изменяет идентификатор сеанса (для предотвращения фиксации сеанса)
  10. Контейнер получает URL целевой страницы с сеанса
  11. Контейнер перенаправляет пользователя на целевую страницу
  12. Пользовательский агент запрашивает целевую страницу
  13. Проверка контейнера для аутентифицированного пользователя
  14. Пользователь аутентифицирован, поэтому контейнер отображает запрашиваемую страницу

Без сеанса контейнер не имеет возможности отслеживать, какие (из потенциально многих) страниц требуют проверки подлинности, которые запрашивал пользователь, и поэтому не могут перенаправить их на запрашиваемую страницу после завершения проверки.

Поделиться
  • 1
    Неординарный ответ! Теперь все кажется очень очевидным. Большое спасибо, Марк!
1

Сессия напрямую не связана с весной-безопасностью, хотя весна-безопасность может ее создать. Сеанс создается контейнером сервлетов на первом этапе getSession(). Может быть Spring-security или любой другой код, который выполняется во время этого первого запроса и вызывает getSession().

Тем не менее, если это вас беспокоит, Spring-security может быть настроен на замену первой сессии "свежей" при аутентификации. Больше информации здесь.

Надеюсь, я помог вам прояснить ситуацию.

Поделиться
  • 0
    Спасибо за ваш ответ. Я думаю, что вы только что объяснили, как в моем вопросе, который также является очень полезной информацией. Однако, похоже, что Spring Security (в данном случае) автоматически создает новый сеанс (и, таким образом, предотвращает атаки с фиксацией сеансов) при входе в систему (и выходе из системы) без необходимости ее программной реализации.
  • 0
    Да, Spring-Security поддерживает это из коробки. Рад, что это помогло.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню