Перехват сеанса: плюсы и минусы фильтра, подавляющего идентификаторы сеанса

Question

Я пытаюсь решить проблему фиксации / перехвата сеанса на сайте ATG / JBoss / Tomcat. Кажется, что на сегодняшний день большинство рекомендаций общего достояния:

1. Предоставить пользователю новый сеанс при входе в систему. Это не позволяет злоумышленнику предсказать идентификатор сеанса жертвы. Сначала я попробовал этот подход, но я боюсь, он может не работать в моем случае

2. Используйте фильтр сервлета для аннулирования сеанса всякий раз, когда в URL передается идентификатор сеанса (SID). Фильтр также предотвращает перезапись URL для создания ссылок с SID

Каковы плюсы и минусы # 2? Некоторые, о которых я думал:

За

1. Это кажется более широкой защитой, чем # 1: # 1 защищает от вредоносных URL-адресов, передаваемых жертве, # 2 защищает от любых способов получения SID (небезопасных беспроводных сетей, доступа к компьютеру и т. Д.) - вы можете ' просто передайте SID, для которого вы хотите использовать параметр запроса!

Против

1. Управление сеансами будет сниматься для пользователей без включенных файлов cookie.
2. Обычные пользователи выйдут из системы, если они нажмут на ссылку с указанной j / jsessionid, хотя я не верю, что в системе будут какие-либо законные ссылки, подобные этой, из-за поведения фильтра.

Answer 1

2 - остановка Фиксация сессии .

Вам также необходимо принять во внимание CSRF aka "Session Riding". Здесь - методы предотвращения CSRF.

Наконец, не забудьте о наиболее пропущенном OWASP, OWASP A9 - Недостаточная защита транспортного уровня .Это означает, что ваш идентификатор сеанса должен передаваться по HTTPS постоянно .Если вы этого не сделаете, кто-то может использовать Firesheep, чтобы захватить учетную запись.

Answer 2

Вы можете сохранить переменную в сеансе, которая содержит IP-адрес пользователя, пользовательский агент и т. Д., Или их хеш-код и проверять его каждый запрос, чтобы в случае его перехвата угонщикам приходилось имитировать их.

Не идеально, но это помогает.