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

Question

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

Answer 1

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

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

Answer 2

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

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

2. в каждом context.xml приложений jboss. D: \ jboss-5.1.0.GA \ сервер \ умолчанию \ Deploy \ jbossweb.sar \ context.xml

Answer 3

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

Answer 4

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

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