Может ли кто-то, кто просто знает мой текущий JSESSIONID, выдать себя за мой сеанс (Tomcat 7/Glassfish 3.2))?

В: Может ли кто-то, кто просто знает мой текущий JSESSIONID, выдать себя за мой сеанс или перехватить его?

О: Да.

Вот почему важно, чтобы ваш сайт был осторожен с файлами cookie. Действительно, если вы беспокоитесь о перехвате пакетов, это означает, что вы должны отправлять файл cookie сеанса только тогда, когда запрос был сделан через соединение HTTPS¹. И установка флага «httpOnly» помогает, останавливая клиентский javascript и т. д. от использования файла cookie.

Вопрос. В каких случаях JSESSIONID будет частью URL-адреса?

A: Обычно это происходит, когда веб-сервер (на уровне контейнера) помещает токен сеанса в URL-адрес:

• как обходной путь для браузера пользователя, не устанавливающего файлы cookie, или
• сделать URL-адрес «подходящим» для добавления в закладки или отправки кому-либо еще по электронной почте.

Очевидно, что это небезопасно и является «плохой практикой»… хотя короткий тайм-аут сеанса, как правило, смягчает это. (В качестве альтернативы можно использовать HTTPS... при условии, что пользователь не передает URL-адрес другим людям¹.)

Для Tomcat 6.x я считаю, что способ предотвратить (когда-либо) добавление контейнером идентификатора сеанса в URL-адрес состоит в том, чтобы добавить атрибут disableURLRewriting="false" в контекст.

Для Томкэт 7:

Context.disableURLRewriting: это было удалено. Аналогичный эффект можно получить, настроив элементы session-config/tracking-mode в веб-приложении или в глобальном файле CATALINA_BASE/conf/web.xml.

^{1. Предполагается, что вы исправили (и т. д.) свой веб-сервер для устранения известных уязвимостей конечной точки SSL. В противном случае ваши HTTPS-соединения могут быть небезопасными.}