Управление сессиями Tomcat - перезапись URL и переключение с http на https

Question

Я старый специалист в C, но неопытный новичок в Java / Tomcat.

Я в порядке с управлением сеансами Tomcat только в http. Когда я пришел посмотреть на переход на https, у меня возникли проблемы.

Я согласен с тем, что Tomcat нужно начинать с сеанса http, если вы хотите поддерживать сеанс при переключении с http на https и обратно на http. Это хорошо работает для меня, когда браузер включен для файлов cookie.

Но если браузер отключен для файлов cookie (и используется перезапись URL), то переключение http на https или обратно приводит к тому, что каждый раз начинается новый сеанс. Я предполагаю, что это вещь безопасности.

В1. Можно ли / желательно поддерживать сеанс между http и https с помощью перезаписи URL?

Q2 - Если это невозможно, то что делают разработчики электронной коммерции для пользователей, не использующих cookie?

Я не хочу, чтобы люди, не использующие файлы cookie, не использовали мой сайт. Мне нужна гибкость при переключении между http и https.

спасибо за любую помощь, Стивен.

Answer 1

Кажется нежелательным поддерживать сеанс между HTTP и HTTPS, используя один и тот же cookie или токен URL.

Представьте себе случай, когда ваш пользователь вошел в систему, когда данный файл cookie (или токен URL) передается взад и вперед для каждого запроса / ответа на веб-сайте электронной коммерции. Если кто-то посередине может прочитать этот cookie, он может войти с ним в HTTP или HTTPS-вариант сайта. Даже если все, что законный пользователь делает затем, работает по протоколу HTTPS, злоумышленник все равно сможет получить доступ к этому сеансу (поскольку у него тоже будет допустимый файл cookie). Он мог видеть такие страницы, как корзина, способ оплаты, возможно, изменить адрес доставки.

Имеет смысл передавать некоторую форму токена между сеансом HTTP и сеансом HTTPS (если вы используете сеансы), но обработка их как одного и того же может привести к некоторой уязвимости. Создание одноразового токена в параметре запроса просто переход может быть решением. Однако вы должны рассматривать их как два отдельных сеанса с проверкой подлинности.

Эта уязвимость может иногда возникать на веб-сайтах, которые используют смешанный контент HTTP и HTTPS (некоторые браузеры, такие как Firefox, будут предупреждать вас, когда это произойдет, хотя большинство людей, как правило, отключают его при первом запуске). У вас может быть файл cookie сеанса HTTPS для главной страницы, но эта страница содержит изображения для логотипа компании через обычный HTTP. К сожалению, браузер отправляет cookie для обоих (так что злоумышленник сможет использовать cookie). Я видел, как это происходит, даже если рассматриваемого изображения даже не было (браузер отправлял запрос с cookie на сервер, даже если он возвращал 404 не найденных).