Управление сеансом Tomcat - перезапись URL и переключение с http на https

Я опытный специалист в C, но новичок в Java / Tomcat.

Меня устраивает только управление сеансами Tomcat в http. Когда я приехал посмотреть на переход на https, у меня были проблемы.

Я понимаю, что для Tomcat вам нужно начать с сеанса http, если вы хотите поддерживать сеанс при переключении с http на https и обратно на http. У меня это нормально работает, когда в браузере разрешены файлы cookie.

Но когда в браузере отключены файлы cookie (и используется перезапись URL), переключение http на https или обратно приводит к тому, что каждый раз запускается новый сеанс. Я предполагаю, что это из соображений безопасности.

Q1 - Возможно / желательно ли поддерживать сеанс между http и https с помощью перезаписи URL?

Q2 - Если это невозможно, то что разработчики электронной коммерции делают с пользователями, не использующими файлы cookie?

Я не хочу препятствовать тому, чтобы люди, не использующие файлы cookie, использовали мой сайт. Мне нужна некоторая гибкость при переключении между http и https.

спасибо за любую помощь, Стивен.


url https session tomcat rewrite
person user373009    schedule 22.06.2010    source источник
comment
(Я использую tomcat 6, JSP, сервлеты, eclipse IDE. Без фреймворка.) Я могу переключиться с http на https, сохраняя тот же URL-адрес, перезаписывая jsessionid, выполнив в JSP: ‹c: url value = / CheckOuter? Cmd = checkout_1 var = goToCheckOut / ›‹ form action = $ {https_name} $ {goToCheckOut} method = post ›и т. д. Но является ли это хорошей практикой?   -  person user373009    schedule 22.06.2010

Ответы (1)


arrow_upward
1
arrow_downward

Кажется нежелательным поддерживать сеанс между HTTP и HTTPS с использованием одного и того же файла cookie или токена URL.

Представьте себе случай, когда вы вошли в систему с заданным файлом cookie (или токеном URL), передаваемым туда и обратно для каждого запроса / ответа на веб-сайте электронной коммерции. Если кто-то посередине может прочитать этот файл cookie, он может затем войти с ним в HTTP- или HTTPS-вариант сайта. Даже если все, что делает законный пользователь, происходит через HTTPS, злоумышленник все равно сможет получить доступ к этому сеансу (потому что у него тоже будет законный файл cookie). Он мог видеть такие страницы, как тележка, способ оплаты, возможно, изменить адрес доставки.

Имеет смысл передавать некоторую форму токена между сеансом HTTP и сеансом HTTPS (если вы используете сеансы), но рассмотрение их как одного и того же может вызвать некоторую уязвимость. Решением может быть создание одноразового токена в параметре запроса только для перехода. Однако вы должны рассматривать их как два отдельных аутентифицированных сеанса.

Эта уязвимость может иногда возникать с веб-сайтами, которые используют смешанный контент HTTP и HTTPS (некоторые браузеры, такие как Firefox, выдают предупреждение, когда это происходит, хотя большинство людей склонны отключать его при первом появлении). У вас может быть файл cookie сеанса HTTPS для главной страницы, но эта страница содержит изображения для логотипа компании через простой HTTP. К сожалению, браузер отправит cookie для обоих (так что тогда злоумышленник сможет использовать cookie). Я видел, как это происходило, даже если изображения, о котором идет речь, даже не было (браузер отправит запрос с файлом cookie на сервер, даже если он вернет 404 not found).

person Bruno    schedule 22.06.2010
comment
Спасибо, Бруно. Я должен подумать об этом. Мне нужен безопасный и надежный сайт. Но я также хочу, чтобы клиент мог свободно перемещаться по сайту. - person user373009; 23.06.2010
comment
К сожалению, когда речь заходит о безопасности, нельзя избежать обучения пользователей. Хитрость в том, чтобы довести его до минимального уровня. Ваши пользователи должны будут ожидать, что они входят или выходят из безопасного места, точно так же, как в настоящее время все проверяют свои браузеры на наличие онлайн-банкинга. Если от вас не ждут, что пользователи будут проверять, их можно обмануть. Злоумышленник вполне может перехватить все простые HTTP-запросы и обработать их напрямую, никогда не отправляя их на страницу HTTPS (или, возможно, ретранслируя их по своему желанию и изменяя содержимое). - person Bruno; 23.06.2010
comment
Я много читал о безопасности / методах Tomcat. На данный момент я намерен: 1) Настроить управляемую контейнером аутентификацию (декларативную, основанную на формах, SSL). 2) Используйте фильтр, чтобы проверить, что IP / user-agent / ssl не меняется в каждом запросе. 3) Рассмотрите возможность отключения перезаписи URL (в основном из-за слухов о том, что это влияет на поисковую оптимизацию Google). еще раз спасибо. Стивен. - person user373009; 23.06.2010
comment
Что касается пункта 2), вам может быть интересно прочитать о подделке межсайтовых запросов (CSRF). Это немного другая проблема, но защита исходного IP-адреса не всегда хорошо, в частности, потому что некоторые пользовательские агенты могут находиться за пулом прокси-серверов с разными IP-адресами. - person Bruno; 23.06.2010