Разрешение фиксации сеанса в JBoss

Мне нужно предотвратить фиксацию сеанса , особый тип перехвата сеанса, в веб-приложении Java, работающем в JBoss. Однако похоже, что стандартная идиома не работает в JBoss . Можно ли это обойти?

Ответов (4)

Решение

Этот дефект (найденный здесь ) указывает путь к решению. Экземпляр Tomcat, работающий в JBoss, настроен с emptySessionPath = "true", а не с "false", которое используется по умолчанию. Это можно изменить в .../deploy/jboss-web.deployer/server.xml ; оба соединителя HTTP и AJP имеют эту опцию.

Сама функция используется для исключения включения контекстного пути (например, "foo" в http://example.com/foo ) в файл cookie JSESSIONID. Установка для него значения false приведет к поломке приложений, которые полагаются на кросс-прикладную аутентификацию, в том числе на вещи, созданные с использованием некоторых фреймворков портала. Однако это не повлияло отрицательно на рассматриваемое приложение.

Я узнал ниже фрагмент настройки кода с одного из форумов. И я добавил строки ниже. Но когда я печатаю идентификатор сеанса после входа в приложение и до него, он остается таким же. Как бы мне протестировать сессию Fixation.

  1. D: \ jboss-5.1.0.GA \ bin \ run.cof и добавьте строку ниже. установите "JAVA_OPTS =% JAVA_OPTS% -Dorg.apache.catalina.connector.Request.SESSION_ID_CHECK = false"

  2. в каждом context.xml приложений jboss. D: \ jboss-5.1.0.GA \ server \ default \ deploy \ jbossweb.sar \ context.xml

Эта проблема и конкретный случай, в котором она возникает, являются проблемой как в Tomcat, так и в JBoss. Tomcat разделяет эффект emptySessionPath = "true" (и фактически JBoss наследует его от Tomcat).

Это действительно похоже на ошибку в Tomcat и JBoss, когда вы пытаетесь предотвратить атаки фиксации сеанса, но спецификация сервлета (по крайней мере, версия 2.3) на самом деле не требует определения или переопределения JSESSIONID в соответствии с какой-либо конкретной логикой. Возможно, это было исправлено в более поздних версиях.

Один из способов решения этой проблемы - сохранить адрес клиента в сеансе. Обертка ответа должна подтверждать, что адрес клиента, установленный в сеансе, совпадает с адресом доступа к сеансу.