Tomcat, продолжайте сеанс при переходе с HTTPS на HTTP

У меня есть приложение Java, работающее на Tomcat 6.0.29, с Apache 2.2.3 спереди. На странице входа используется HTTPS, в то время как на большинстве страниц используется HTTP.

Если пользователь пытается получить доступ к странице (HTTP), защищенной от входа в систему, он перенаправляется на страницу входа в систему (HTTPS), регистрируется, а затем перенаправляется обратно на первоначально запрошенную страницу. Это отлично работает, поскольку cookie JSESSIONID устанавливается как незащищенный и используется как для HTTP, так и для HTTPS.

Однако, если пользователь запустится на странице входа в систему (HTTPS), cookie JSESSIONID устанавливается как безопасный, и поэтому сеанс недоступен после входа в систему при перенаправлении на страницы под HTTP, форсировании нового сеанса и перенаправлении на страницу входа в систему еще раз. На этот раз он работает, потому что на этот раз cookie JSESSIONID установлен как незащищенный.

Как я могу избежать, чтобы пользователи дважды регистрировались, когда они сначала попали на страницу входа?

Ответы

Ответ 1

(Обновление: для ясности). Начиная с входа в систему Http get/post, используйте https и используйте https через пользователя, вошедшего в сеанс.

Использовать Http только при отсутствии входа в систему.

Существует причина, по которой файлы cookie не позволяют перекрещивать границы протокола - это вектор атаки! (* см. обновление ниже)

Как сделать эту очень плохую идею

Если вы действительно настаиваете, закодируйте jsessionId в перенаправлении на http-url (или всегда кодируйте id jsession в URL-адресе). Когда Tomcat получает перенаправление http, tomcat должен найти сеанс и продолжить.

Почему вы не должны этого делать

Серьезно, любой сайт, который смешивает https и http-контент на одной странице, просто открывает себя для всех видов забавных (и легких) атак.

Переход с https для сохранения "безопасного" входа в систему бессмыслен, если остальная часть сеанса находится в открытом виде. Итак, что такое имя пользователя/пароль (возможно, только пароль) защищено?

Используя популярную атаку "человек-в-середине", злоумышленник просто копирует идентификатор сеанса и использует его для развлечения. Поскольку большинство сайтов не заканчивают сеансы, которые остаются активными, MIM эффективно имеет полный доступ, как если бы у них был пароль.

Если вы считаете, что https стоит с точки зрения производительности, посмотрите здесь или просто выполните поиск. Самый простой способ повысить производительность https до приемлемого - убедиться, что сервер настроен на поддержание связи в соединении.