Ничто не мешает этому.Вы получаете идентификатор сеанса, вы можете принять участие в сеансе.
В обычном случае с файлами cookie это не является само по себе риском.Злоумышленник не сможет прочитать файл cookie сеанса пользователя, кроме случаев, когда:
у них есть возможность «человек посередине», и в этом случае у вас гораздо более серьезные проблемы, чемтолько идентификаторы сеанса;
вы оставили дыру в межсайтовом скриптинге, и в этом случае у вас проблемы намного хуже, чем просто идентификаторы сеанса;
вы уязвимы для атак связывания DNS / междоменных приготовлений, и в этом случае вы должны исправить это, разрешив только хорошо выполненные Host: запросы.
(Хотя вы можете попытаться связать сеансы с IP-адресами, это может привести к срыву действительных сеансов, например, из-за циклического прокси-сервера. IP-адреса могут использоваться как часть более широкой стратегии обнаружения подозрительной активности, но в общедоступном Интернете это не очень хорошая идеявсегда требовать, чтобы каждый запрос в сеансе приходил с одного и того же IP-адреса.)
К сожалению, в сервлете есть еще один случай, кроме файлов cookie: jsessionid= параметры.Так как они появляются в самом URL, это делает их намного более утечечными (например, через рефереры и вставленные ссылки).И это далеко не единственная практическая проблема с идентификаторами сеансов параметров.Они портят навигацию и портят SEO.
На мой взгляд jsessionid= URL-адреса - одна из худших ранних ошибок Servlet, дискредитированная стратегия возврата файлов cookie из прошлых лет, которая не должна использоваться ни для чего.Но, конечно, им нельзя разрешать предоставлять доступ к любым привилегированным данным;рассмотрите возможность использования HTTP Basic Authentication вместо этого, если вам нужен механизм отката для браузеров, которые не поддерживают куки.
В Servlet 3.0 вы можете легко отключить jsessionid= URL, используя <session-config> в web.xml;к сожалению, в предыдущих версиях вы оставались бездельничающими с фильтрами, если хотите правильно отключить эту функцию.