Токен CRSF и репликация сеанса с Tomcat и Apache

Question

У меня есть J2EE-совместимое веб-приложение. Я использую токен на основе сеанса, чтобы добавить вторичный идентификатор ко всем входящим ссылкам, созданным моим приложением. Чтобы предотвратить применение приложения к CSRF-атаке, я проверяю вторичный идентификатор, прежде чем разрешить сеансу пользователя отработать следующую страницу.

Недавно, работая с реализацией механизма репликации сеанса, я заметил, что при переключении сеанса сгенерированный вторичный идентификатор теряется, и пользователь перенаправляется на страницу входа / страницу по умолчанию.

Любые предложения о том, как я могу гарантировать, что мой сгенерированный вторичный идентификатор токена не будет потерян из реплицируемого сеанса?

Answer 1

Простой вторичный токен обеспечивает только ограниченную защиту от CSRF-атак. Для нашей собственной инфраструктуры ( pulse ) мы решили подписать каждый URL-адрес, создав собственный хэш-код для URI, который затем добавляется с сохраненным в сеансе секретом (Long, который сериализуется из коробки), а затем переваривается с помощью SHA-256. Таким образом, секрет не раскрывается при добавлении в URI. Весь процесс легко контролируется аннотацией (@RequireToken)

Answer 2

Объект, представляющий токен, должен реализовывать java.io.Serializable, чтобы выжить всякий раз, когда сеанс должен храниться / считываться / передаваться в виде двоичного потока (по сети, в файловой системе диска и т. Д.), Как это происходит в механизмах репликации сеанса и восстановления после отказа.,

Обычно это прямо упоминается в документации к рассматриваемому механизму.Я бы посоветовал прочитать его еще раз, чтобы убедиться, что вы охватили все, чтобы обеспечить безупречную работу репликации / отработки отказа.

Вот выдержка из Tomcat 6.0 документации относительно предмета,из главы Основы кластера :

Чтобы запустить репликацию сеанса в контейнере Tomcat 6.0, необходимо выполнить следующие шаги:

• Все ваши атрибуты сеанса должны реализовывать java.io.Serializable
• ...