Проблема с функцией безопасности сеанса JBoss 6 с использованием сервлета 3.0 - PullRequest
Новая
       33

Проблема с функцией безопасности сеанса JBoss 6 с использованием сервлета 3.0

12 голосов
/ 25 июня 2011

Мы перенесли наше приложение с JBoss 5 на JBoss6, и одной из основных причин этого является использование новых функций сервлета 3.0. Все работает отлично, за исключением одной новой функции JBoss 6 и сервлета 3.0: настройка cookie сеанса для передачи только по безопасному каналу, даже если запрос был сделан через обычный HTTP. Это очень важная функция безопасности для нас и достигается добавлением 

<secure>true</secure>

в web.xml. Это часть нашего web.xml: 

<session-config>
<session-timeout>25</session-timeout>
<cookie-config>
    <http-only>true</http-only>
    <secure>true</secure>
</cookie-config>
<tracking-mode>COOKIE</tracking-mode>

Когда мы удаляем 

<secure>true</secure>

все отлично работает. Когда он есть, для каждого запроса генерируется новый jsessionid, даже если он находится на защищенной странице (HTTPS) или на незащищенной странице (HTTP). Кроме того, вход в систему не работает, поскольку после входа в систему с безопасными учетными данными пользователь перенаправляется обратно на страницу входа.

Полагаю, это также может быть проблемой с Tomcat 7, поскольку он также использует спецификацию сервлета 3.0. Любой совет будет высоко ценится.

Привет

1 Ответ

2 голосов
/ 16 августа 2014

Согласно спецификации HTTP :

Безопасный

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

Пользовательский агент (возможно, под контролем пользователя).) может определить, какой уровень безопасности он считает подходящим для «безопасных» файлов cookie .Атрибут Secure должен рассматриваться как совет по безопасности от сервера агенту пользователя, что указывает на то, что сеанс заинтересован в защите содержимого cookie.

Это означает, что спецификация оставляет его открытым для браузера (пользовательский агент), чтобы определить, что является «безопасным».

Элемент Secure в web.xml является ссылкой на свойство HTTP Cookie Secure *1020*, и вы можете отслеживать это значение с помощьюинструмент отладки вашего браузера.

Если обмен данными не является "безопасным", браузер не будет отправлять полученный файл cookie на сервер при следующих запросах.

Проблема заключается не в том, что JBoss всегда возвращает новые файлы cookie, а в том, чтобраузер, который не отправляет его обратно, потому что общение небезопасно.Затем JBoss создает новый сеанс для каждого запроса.

Совершенно очевидно, что для незашифрованной связи (не HTTPS) браузер не будет отправлять cookie, это ожидается, так как вы отмечаете cookie как secure = true.

Но, даже если вы используете HTTPS, «безопасный» равен относительно относительно концепции безопасности браузера, например:

  • Срок действия сертификата может истечь
  • Сертификат самоподписан
  • Вы используете имя хоста, отличное от того, который подписал сертификат

Эти ипри использовании TLS могут возникнуть другие проблемы с безопасностью, что означает, что связь не защищена.

Проблема должна быть в конфигурации SSL / TLS или Cookie, что означает, что вы должны проверить, что вы сделалии изолировать проблему.Я не думаю, что есть какая-либо ошибка в JBoss или JBossWeb (Tomcat 6 fork), вызывающая ее, и наверняка это не ошибка спецификации.

Мне удалось настроить JBoss 6.1.0 Final с TLSи с вашей web.xml конфигурацией, и все работает как положено.

Я предлагаю вам еще раз проверить вашу конфигурацию, отладку браузера и оповещения.

...