JSESSION / HTTPSession против идентификатора сеанса, созданного приложением

Question

В веб-приложении, основанном на пропрайтинге MVC и модели авторизации, мы недавно перешли на Spring MVC. В рамках этого шага мы также рассматриваем отход от локально созданного GUID, который передается с каждым запросом в идентификатор сеанса на основе файлов cookie.

На первый взгляд, похоже, что в нашем случае это будет большим недостатком, так как стандарт JSESSION / HttpSession, по-видимому, является корнем всех зол безопасности:

1. Фиксация сессии (В существующем коде сессия создается только после успешного входа в систему, поэтому нам никогда не нужно аннулировать () сессии.
2. CSRF - Сессия никогда не передается как cookie, так что это никогда не является риском (и, боже, с этим проблематично обращаться, так как нет реальных рамок или общего решения, проверенных HDIV и CSRFGuard).
3. Удобство тестирования - QA может легко подключать к одному серверу нескольких пользователей с несколькими ролями, что невозможно с JSESSION.
4. В согласованном создании HTTPSession и аннулирования в различных контейнерах (Weblogic, JBOSS и Websphere)
5. Несовместимая обработка JSession при переходе от HTTP к HTTPS.

Итак, кроме очевидного преимущества "быть стандартным", есть какие-либо подсказки относительно того, почему я хочу пойти по пути JSESSION?

Answer 1

Не совсем категоричный ответ о том, почему вы должны или не должны использовать jsession, но приведу несколько замечаний относительно вашей озабоченности:

1. Ваше приложение не должно полагаться на тот факт, что сеанс существует или нет.Он должен опираться на тот факт, что сеанс действителен в соответствии с определенными правилами, которые вы на него наделили (аутентификация пользователя, роли, назначенные этому пользователю и т. Д.)
2. CSRF на самом деле не имеет большого значения, есливы позаботитесь о том, чтобы не использовать GET для разумных действий, и, как вы упомянули Spring MVC, этого легко достичь.
3. Верно, если вы полагаетесь только на один браузер.И, как примечание, хотя для некоторых ситуаций ручное тестирование остается обязательным, во многих случаях может быть полезна автоматизация, что снижает влияние необходимости переключаться с одной роли на другую.
4. Никогда не сталкивайтесь с проблемойтот.Но я старался, чтобы содержание сессии было как можно меньше.
5. И это хорошо.Это может помешать вам отойти от вашего безопасного соединения, не заметив его.

Теперь, какой бы вариант вы ни выбрали, у вас всегда будут некоторые недостатки.Наличие UUID в каждом запросе (и, следовательно, потенциально в каждом GET URL) не позволяет вашим пользователям легко использовать закладки.И не поддерживать их сессию.

Answer 2

После долгих дискуссий, анализа и тестирования, кажется, что в моем случае, приложение без RESTfull, с рабочим столом, таким как RIA UI, и широким рассмотрением вопросов безопасности, JSESSION - не самый лучший способ (в основном CSRF) и лучший вариант.является внутренним сгенерированным ключом, основанным на телеЭто, однако, означает, что приложение будет вынуждено обрабатывать тайм-ауты и отмену сеанса.