Использование идентификатора сеанса способом, который предлагает dan_waterworth, хотя и является простым, является очень плохой защитой.Злоумышленнику нужно только перехватить cookie-файл идентификатора сеанса, а затем обойти защиту в течение всего сеанса.
Идентификатор сеанса является файлом cookie, поэтому он отправляется с любым запросом.Таким образом, все, что нужно злоумышленнику для захвата sessionid, - это заставить ваше приложение отправить запрос на сервер под контролем злоумышленника.Это может быть сделано с помощью межсайтовой скриптинговой атаки, но также может быть сделано путем создания приложения и отправки форм iFrame (есть другие способы сделать это).
Взаимодействие, которое должно быть защищено от CSRF, должно включать информацию, которую злоумышленник не может знать заранее (токен CSRF), который уникален для сеанса, для страницы и для формы, а затем в идеале должен использоваться только один раз.Маркер CSRF должен быть представлен в форме, а не в файле cookie (по причине, указанной выше).Для получения подробной информации и примера реализации см. «Пример реализации» в листе защиты OWASP CSRF.Некоторые механизмы веб-приложений (например, Tomcat 8) и фреймворки (например, Spring, JSF) имеют защиту, которую вы можете применить, включив конфигурацию.