Jetty / Tomcat зашифрованное хранилище сеансов на основе файлов cookie?

Question

Ruby on Rails уже давно поддерживает подписанные сеансы на основе файлов cookie , и с тех пор появилось несколько зашифрованных реализаций . Python и PHP также имеют реализации.

Существует ли такой зверь для контейнеров сервлетов Java Jetty или Tomcat?

Мы получили значительное повышение производительности по сравнению с сеансами на основе RDBMS с реализацией PHP в нашей кластерной среде, и мне было бы интересно попробовать нечто подобное с одним из наших приложений Java (которое в настоящее время использует Jetty 7).

Мне известны другие способы достижения этой цели ( memcached , синхронизированные в памяти кэши), но я считаю, что для наших конкретных потребностей существуют ограничения этого метода хранения (сеансызавершение перед выводом, неэффективное хранение после ограничения размера файла cookie 4K, зависимость от сверхсекретного ключа на стороне сервера) перевешиваются более простой средой развертывания для этого конкретного приложения.

Если реализация несуществует, у кого-нибудь есть идеи, почему бы и нет?(например, сеансы Java обычно имеют размер более 4 КБ, и поэтому они не поддаются такому способу хранения)

Answer 1

Мы внедрили Session-In-Cookie и успешно использовали его в кластере Tomcat, чтобы обеспечить совместное использование сеанса между 20 узлами и, таким образом, обеспечить развертывание без сбоев. Я только что написал первую часть серии из двух частей о реализации здесь: http://blog.shinetech.com/2012/12/18/simple-session-sharing-in-tomcat-cluster-using-the-session-in-cookie-pattern/. Эта часть касается базовой реализации, аспекты безопасности будут рассмотрены во второй части.

Answer 2

Кажется, здесь есть два вопроса:

1. Реализации Java / J2EE для эффективного управления сеансами без сохранения состояния.
2. Безопасные реализации сеанса.

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

Относительно второго вопроса: защита сессий - другой вопрос. Общеизвестный файл cookie JSESSIONID в системах Java / J2EE - это простой ключ-токен для сеанса в памяти или в кэше на сервере приложений. Это просто ключ карты. С этим ключом любой может украсть или выдать себя за пользовательский сеанс. Это, вероятно, одно из самых слабых звеньев во всем управляемом контейнером сеансовом устройстве. Доступны коммерческие продукты для защищенных сеансов, которые предотвращают перехват сеансов с помощью кражи файлов cookie, предотвращают повторные атаки (которые могут победить SSL путем захвата воспроизведения зашифрованного сеанса входа в систему для получения сеанса) и другие векторы атак. Один продукт, о котором я знаю, может сделать это без изменений в коде (через фильтр безопасности). Однако я не знаю каких-либо общих структур или инициатив с открытым исходным кодом, чтобы закрыть эту дыру, возможно, потому, что для этого требуется уровень знаний, выходящий за рамки общей разработки приложений.

Answer 3

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