Идентификатор сеанса повторно используется после вызова для аннулирования - PullRequest
Новая
       22

Идентификатор сеанса повторно используется после вызова для аннулирования

5 голосов
/ 26 июля 2011

Я унаследовал довольно древнее приложение JSP (JDK 1.3.1_15) и пытаюсь закрыть дыру в фиксации сеанса.

Я успешно аннулирую текущий сеанс после аутентификации с использованием HttpSession.invalidate(), однако, когдановый сеанс создан, старый идентификатор сеанса используется повторно. 

<%
// login.jsp
if (authenticated) {
    request.getSession().invalidate();

    // create new session and store data
    HttpSession session = request.getSession();
    session.putValue(...);
    // etc

    response.sendRedirect("logged-in.jsp");
    return;
}
%>

Я вижу новое назначение сеанса в моем мониторе HTTP, просто снова используется тот же номер. 

-- Initial request response --
HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=6a303082951311647336934;path=/

-- login.jsp request response --
HTTP/1.1 302 Moved Temporarily
Location: http://example.com/logged-in.jsp
Set-Cookie: JSESSIONID=6a303082951311647336934;path=/

До того, как я использовал session.invalidate(), второй Set-Cookie заголовок ответа вообще не присутствовал.

У кого-нибудь есть какие-либо советы по созданию нового идентификатора сеанса?Я не очень знаком с JRUN4, но просмотр документации по конфигурации ничего не дал.

Ответы [ 2 ]

3 голосов
/ 31 июля 2011

Чтобы обойти это, вы можете использовать второй непостоянный файл cookie, чтобы действовать в качестве идентификатора сеанса, значение которого вы можете контролировать. Идея состоит в том, чтобы создать уникальный идентификатор и сохранить его как в файле cookie, так и в сеансе. Реализуйте ту же логику с этим файлом cookie, которую вы пытаетесь сделать с помощью сеанса с помощью invalidate. В частности, не выдавайте фактический идентификатор, который будет принят для будущих запросов, пока аутентификация не будет успешной. Затем создайте фильтр сервлетов, который проверяет каждый запрос и сопоставляет значение этого нового файла cookie со значением, сохраненным в сеансе. Если они не совпадают, происходит что-то гнусное. Я знаю, что это немного более обременительно, чем просто полагаться на session.invalidate() для выдачи нового идентификатора. Но, учитывая ваши ограничения и поведение JRun, это обеспечит достаточную защиту от фиксации сеанса.

1 голос
/ 29 июля 2011

Из Раздела 7.3 спецификации Java Servlet 3.0 вы можете видеть, что:

Объекты HttpSession должны быть ограничены в приложении (или сервлете). контекст) уровень. Базовый механизм, такой как cookie, используемый для установить сеанс, может быть одинаковым для разных контекстов , но ссылка на объект, включая атрибуты этого объекта, никогда не должна быть разделенным между контекстами контейнером.

Это действительно ужасная идея, но мне интересно, если cookie-файл JSESSIONID просто повторно используется и фактический контекст сеанса уничтожен. Можете ли вы по-прежнему иметь доступ к состоянию (то есть атрибутам) недействительного сеанса?

...