Если приложение перенаправляет пользователя на страницу входа в Keycloak и находится там дольше, чем «время ожидания входа» (по умолчанию 5 минут), то, когда пользователи вводят имя пользователя и пароль, вместо входа в систему ее приветствует:
Вы слишком долго авторизовались. Процесс входа в систему начинается с самого начала.
Чтобы избежать этого, можно изменить «Настройки области → Токены → Время ожидания входа», например, на 10000 дней, что составляет 27 лет, что должно гарантировать, что это никогда не произойдет в реальности.
Но прежде чем мы продолжим и эффективно отключим этот тайм-аут, мы хотели бы спросить: какова цель этого тайм-аута? Кто-то явно потрудился реализовать его, но от чего он защищает? Каковы (безопасность?) последствия его отключения?
Насколько мне известно, в основном используется как дополнительный механизм для избежания атак фиксации сессии. Например, в компании пользователь идет выпить кофе и оставляет компьютер включенным, а затем хакер видит возможность и вручную устанавливает в URL-адресе браузера
текущий логин session ID
(или просто копирует). Теперь, если система настроена таким образом, что session ID
не меняется между фазами входа до и после входа. Затем, после успешной аутентификации жертвы, хакер сможет использовать без какой-либо аутентификации сеанс, в котором жертва находится в данный момент;
Чем выше тайм-аут, тем шире будет окно возможностей для таких атак. Тайм-аут входа в систему — это еще один уровень защиты, позволяющий избежать таких проблем, поскольку это истечение срока действия сеанса, изменение идентификатора сеанса между этапами до входа и после входа в систему, среди прочего.
Более формально можно прочитать в (источник).
Тайм-аут первоначального входа в систему Этот дополнительный механизм защиты пытается принудительно обновить предварительной аутентификации идентификатора сеанса, избегая сценариев, в которых ранее используемый (или установленный вручную) идентификатор сеанса повторно используется следующей жертвой с использованием тот же компьютер, например, при атаках с фиксацией сеанса.
И с OWASP.org
Session Fixation — это атака, которая позволяет злоумышленнику захватить действительный сеанс пользователя. Атака исследует ограничение в том, как веб-приложение управляет идентификатором сеанса, а точнее уязвимое веб-приложение. При аутентификации пользователя не назначить новый идентификатор сеанса, что позволит использовать существующий сеанс ИДЕНТИФИКАТОР. Атака состоит в получении действительного идентификатора сеанса (например, подключение к приложению), побуждение пользователя к аутентификации себя с этим идентификатором сеанса, а затем перехватив проверенный пользователем сеанс, зная идентификатор используемого сеанса. Злоумышленник должен предоставить допустимый идентификатор сеанса веб-приложения и попытаться сделать браузер жертвы использует его.
Довольно хорошее объяснение того, как работают атаки фиксации сеанса и как их предотвратить здесь и здесь.
Я не эксперт по безопасности, но я бы сказал, что если у вас есть другие механизмы предотвращения, такие как изменение идентификатора сеанса, все будет в порядке. Однако, с другой стороны, вам действительно нужно так много времени для входа в систему? И разве это сильно раздражает, чтобы просто обновить снова?
Спасибо за отличный ответ. Именно то, на что я надеялся. Да, я не думаю, что нашей команде по управлению продуктами понравится "Вы слишком долго входите в систему. Процесс входа начинается с самого начала". Теперь, благодаря вашему ответу, у меня есть факты, чтобы мы вместе могли принять обоснованное решение.