Если вы используете токены сеансов для поддержки активных сеансов (стандартная и устоявшаяся практика) по HTTP, вы уязвимы для перехвата сеансов, когда любой, кто может перехватить действительный поток трафика, может получить этот токен и использовать его повторно.
Если вы хотите предотвратить это, вам необходимо провести все ваши взаимодействия с пользователем по SSL / TLS, так как тогда токен будет отправляться только через зашифрованный туннель.
Если выне можете этого сделать, значит вы уязвимы.Вы можете ввести некоторый уровень смягчения этого риска, выполнив такие вещи, как привязка токена сеанса к IP-адресу (принимать токен сеанса только в том случае, если он представлен тем же IP-адресом клиента, который был ему выдан), но затемоткрытие банка червей при изменении IP-адресов (представьте, например, что пользователь вошел на ваш сайт, а затем, например, перемещает беспроводные сети).
Вы должны спросить, является ли эта угроза достаточно серьезной, чтобы вы могли ее устранить.Какой тип данных обрабатывается вашим приложением?Если он чувствительный, то вам, вероятно, нужно его защитить ... если он общедоступен, и вы просто используете логины пользователей для отслеживания того, кто к чему имеет доступ, то, возможно, вы этого не делаете. Все зависит от вашего анализа рисков.
Есть несколько других идей на веб-странице OWASP Session Management ... но если вам действительно нужно противостоять этой угрозе, тогда вам нужно проводить все ваши взаимодействия по SSL / TLS.