Метод, используемый для генерации токена, не очень важен. Важно то, что токен будет использоваться только один раз. Храните список токенов, сгенерированных для пользователя, в сеансе пользователя. Если пользователь отправляет форму, а отправленный токен отсутствует в сеансе, вы можете отклонить форму.
Защита от человека посередине немного сложна. Обычная техника, которую я видел, - это включение всех скрытых полей формы в хеш-функцию для генерации токена, а затем регенерация токена на основе известных скрытых полей. Однако это защитит только от скрытых манипуляций с полем, которые не могут быть конечной целью человека в середине.
Когда пользователь успешно отправит форму с токеном, удалите токен из сеанса, поэтому любое воспроизведение этой отправки завершится неудачно. Тем не менее, все, что требуется, это пользователь, снова запрашивающий форму для создания другого токена. Этот новый токен может быть использован в последующих автоматических атаках. Другими словами, токены форм полезны против CSRF, но не очень эффективны против автоматических реплеев и атак «человек посередине».
Аналогично, вы захотите адаптировать свое приложение так, чтобы оно не требовало использования кнопки «Назад» в формах. Если существует проблема с их отправкой, вам нужно будет вернуть форму обратно пользователю с заполненными данными. Если пользователь нажмет на кнопку «Назад», чтобы исправить ошибку, его отправка не удастся из-за того, что теперь она недействительна. лексема.
Кроме того, честно говоря, к тому времени, когда вам нужно беспокоиться о повторных запросах и атаках типа «человек посередине», соединение вашего пользователя уже взломано, и вы, вероятно, не так уж много можете сделать, чтобы уменьшить любой ущерб. SSL сам по себе является достаточным уровнем защиты от MITM и воспроизведения, и если вас это беспокоит, вы будете работать под SSL ...