Tomcat, продолжай сеанс при переходе с HTTPS на HTTP - PullRequest
Новая
       39

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

11 голосов
/ 08 января 2011

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

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

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

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

1 Ответ

7 голосов
/ 10 января 2011

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

Используйте Http, только когда нет зарегистрированныху пользователя.

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

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

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

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

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

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

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

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

...